Làm thế nào cookie hoạt động với bộ cân bằng tải không liên tục

Chúng tôi có một ứng dụng Drupal sử dụng sso để đăng nhập người dùng.

Chúng tôi đang sử dụng bộ cân bằng tải cổ điển AWS (ELB), AWS đang nói với chúng tôi rằng không có sự kiên trì phiên nào trên ELB.

Những gì tôi đang cố gắng tìm ra là làm thế nào cookie hoạt động với sự không kiên trì trên các bộ cân bằng tải cổ điển.

example.com DNS được trỏ đến ELB. Có 2 máy chủ trong nhóm Server1 và Server2

Điều chúng tôi muốn xảy ra là nếu người dùng truy cập trang chủ của họ http://example.com/user/12345/trên máy chủ 1 nếu họ chưa đăng nhập thì họ đã được chuyển hướng đến trang sso http://example.com/user/login/sso, tự động đăng nhập và nhận cookie SESS<hexnumber>và sau đó được chuyển hướng trở lạihttp://example.com/user/12345/

Chúng tôi không được phép thêm bất kỳ máy chủ phiên nào (redis), đảm bảo rằng chúng sẽ ở lại trên máy chủ 1 cho cả hai chuyển hướng.

Theo hiểu biết của tôi với mỗi lần truy cập vào 'example.com', người dùng có thể kết thúc trên máy chủ 1 hoặc máy chủ 2.

Câu hỏi của tôi:

Nếu họ nhận được cookie trên server1 và sau đó được chuyển hướng đến server2 thì làm sao server2 biết rằng cookie đã được gán cho người dùng đó trên server1?

Tôi dường như đang suy nghĩ trong vòng tròn. Khi làm việc với loại thiết lập này trong quá khứ bằng cách sử dụng LB mà không có sự kiên trì của phiên, chúng tôi đã sử dụng máy chủ redis để giữ các phiên và mỗi yêu cầu sẽ xem xét redis sever để biết thông tin phiên.

Một cookie được đặt trong trình duyệt, không phải trong máy chủ. Nó được giới hạn trong một tên miền và, tùy ý, một đường dẫn cụ thể trong URL, miễn là cả hai máy chủ được truy cập bởi cùng một tên miền, cookie sẽ ở đó.

Nếu một cookie trỏ đến một phiên, thì điều cần thiết là cả server1 và server2 đều có quyền truy cập vào phiên đó theo một cách nào đó. Nếu các phiên không thể được chia sẻ giữa các máy chủ thì bạn cần buộc người dùng phải kiên trì đến một máy chủ cụ thể. Điều này có thể dễ dàng thực hiện với DNS và một chút ma thuật viết lại URL:

• www.example.com trỏ đến cả hai máy chủ.
• www1.example.com chỉ trỏ đến server1
• www2.example.com chỉ trỏ đến server2

Sử dụng một bộ quy tắc viết lại (ish) đơn giản và cookie, người dùng sau đó có thể bị khóa vào một máy chủ cụ thể, đảm bảo rằng phiên của mình vẫn tồn tại.

Dưới đây là một số chi tiết.

DNS:

• example.com A 1.1.1.1, A 2.2.2.2
• www.example.com CNAME example.com
• www1.example.com A 1.1.1.1
• www2.example.com A 2.2.2.2

Viết lại quy tắc:

• cookie kiên trì: "phụ trợ"
• kết nối ban đầu: "phụ trợ" không được xác định, đặt "phụ trợ" thành www1 hoặc www2, tùy thuộc vào máy chủ nào đã trả lời và chuyển hướng đến máy chủ đó. Cookie phải được đặt thành tên miền "example.com", theo cách này, nó sẽ được tải trên cả www1 và www2
• Nếu "phụ trợ" được xác định, đảm bảo rằng giá trị của nó khớp với phiên bản máy chủ và chuyển hướng nếu cần.
• Đảm bảo rằng cookie phiên được xác định trong tên miền đầy đủ của máy chủ - đó là www1.example.com hoặc www2.example.com

Logic viết lại sẽ được xác định trong chính máy chủ web. Tất cả các máy chủ web hiện đại đều có ngôn ngữ viết lại rất đặc trưng, ​​hoàn toàn có khả năng thực hiện chức năng này.

Nếu bạn không thể sử dụng cơ sở dữ liệu quản lý phiên như Elasticache Redis (Redis cho các phiên không nên tốn hơn 15 đô la mỗi tháng), thì tùy chọn tốt nhất tiếp theo là bật các phiên dính trên ELB;

https://docs.aws.amazon.com/elasticloadbalANCE/latest/ classic / elb-sticky-simes.html

Điều này sẽ buộc người dùng goto cùng một nút phụ trợ trong suốt phiên. Một "cookie cân bằng tải được tạo ra" với thời gian 900 giây là đủ tốt nhưng bạn có thể điều chỉnh điều này.