8

Tôi đã có một trang web chạy trên Amazon Web Services được triển khai bằng Elastic Beanstalk và chạy trên tối thiểu 2 trường hợp vi EC2. Một chính sách tự động mở rộng quy mô được đặt ra, để nó có thể mở rộng quy mô và quy mô tùy thuộc vào lưu lượng truy cập trong trang web. Vì chính sách mở rộng quy mô tự động này, tôi muốn tránh sử dụng các phiên cố định và vì lý do đó tôi đang sử dụng memcached-session-manager. Tôi đang sử dụng Amazon ElastiCache (ví dụ nhỏ) cho máy chủ memcached.memcached-session-manager trên AWS

Cấu hình trong context.xml là như sau:

<Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager" 
    memcachedNodes="sessions.myinstancecode.0001.use1.cache.amazonaws.com:11211" 
    sticky="false" 
    sessionBackupAsync="false" 
    lockingMode="none" 
    transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory" /> 

này hoạt động tốt khi lưu lượng thấp (ví dụ: ít hơn 10 người dùng trực tuyến) nhưng đôi khi gây ra các trường hợp EC2 để khởi động lại. Bạn có thể tưởng tượng rằng nếu trang web hiện đang chạy trên hai trường hợp và cả hai đều quyết định khởi động lại cùng một lúc, trang web trở nên không thể truy cập được và đó là một vấn đề lớn. Đây là những dòng cuối cùng trong tail_catalina.log được luân chuyển trên Amazon S3 trước khi dụ EC2 quyết định khởi động lại:

Jun 13, 2012 12:32:27 AM de.javakaffee.web.msm.BackupSessionTask handleException 
WARNING: Could not store session 42F9761AC24F826E1FC3F2A834FBF442 in memcached. 
Note that this session was relocated to this node because the original node was not available. 
net.spy.memcached.internal.CheckedOperationTimeoutException: Timed out waiting for operation - failing node: sessions.myinstancecode.0001.use1.cache.amazonaws.com/10.194.23.99:11211 
    at net.spy.memcached.internal.OperationFuture.get(OperationFuture.java:73) 
    at de.javakaffee.web.msm.BackupSessionTask.storeSessionInMemcached(BackupSessionTask.java:230) 
    at de.javakaffee.web.msm.BackupSessionTask.doBackupSession(BackupSessionTask.java:195) 
    at de.javakaffee.web.msm.BackupSessionTask.call(BackupSessionTask.java:120) 
    at de.javakaffee.web.msm.BackupSessionTask.call(BackupSessionTask.java:51) 
    at de.javakaffee.web.msm.BackupSessionService$SynchronousExecutorService.submit(BackupSessionService.java:339) 
    at de.javakaffee.web.msm.BackupSessionService.backupSession(BackupSessionService.java:198) 
    at de.javakaffee.web.msm.MemcachedSessionService.backupSession(MemcachedSessionService.java:967) 
    at de.javakaffee.web.msm.SessionTrackerValve.backupSession(SessionTrackerValve.java:226) 
    at de.javakaffee.web.msm.SessionTrackerValve.invoke(SessionTrackerValve.java:128) 
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) 
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) 
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98) 
    at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:680) 
    at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:928) 
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) 
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) 
    at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987) 
    at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:539) 
    at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:298) 
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) 
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) 
    at java.lang.Thread.run(Thread.java:636) 
Jun 13, 2012 12:32:28 AM de.javakaffee.web.msm.LockingStrategy onAfterBackupSession 
WARNING: An error occurred during onAfterBackupSession. 
net.spy.memcached.internal.CheckedOperationTimeoutException: Timed out waiting for operation - failing node: sessions.myinstancecode.0001.use1.cache.amazonaws.com/10.194.23.99:11211 
    at net.spy.memcached.internal.OperationFuture.get(OperationFuture.java:73) 
    at de.javakaffee.web.msm.LockingStrategy.onAfterBackupSession(LockingStrategy.java:287) 
    at de.javakaffee.web.msm.MemcachedSessionService.backupSession(MemcachedSessionService.java:970) 
    at de.javakaffee.web.msm.SessionTrackerValve.backupSession(SessionTrackerValve.java:226) 
    at de.javakaffee.web.msm.SessionTrackerValve.invoke(SessionTrackerValve.java:128) 
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) 
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) 
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98) 
    at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:680) 
    at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:928) 
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) 
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) 
    at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987) 
    at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:539) 
    at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:298) 
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) 
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) 
    at java.lang.Thread.run(Thread.java:636) 

Nó có vẻ như nút Amazon ElastiCache là thất bại, nhưng điều này là, kiểm tra trên Amazon CloudWatch, tôi có thể thấy rằng việc sử dụng CPU không bao giờ vượt quá 8%. Có lý do nào khiến nút Amazon ElastiCache không thành công, mặc dù nó không bị nhấn mạnh đến mức đó? Ngoài ra, tại sao Amazon quyết định khởi động lại (hoặc tốt hơn: chấm dứt và bắt đầu một cá thể mới) khi nút Amazon ElastiChace không thành công?

Bất kỳ trợ giúp nào được đánh giá cao.

Cảm ơn!

Trả lời

7

Bạn nên tăng sessionBackupTimeout của memcached-phiên-manager, từ documentation:

sessionBackupTimeout (không bắt buộc, mặc định 100)

Thời gian chờ trong mili giây sau đó sao lưu một phiên được coi như beeing thất bại. Thuộc tính này chỉ được đánh giá nếu phiên được lưu trữ đồng bộ (được đặt qua sessionBackupAsync). Giá trị mặc định là 100 mili giây.

Các vấn đề liên quan