Cara kerja cookie dengan balencers non persistent load

Kami memiliki aplikasi Drupal yang menggunakan sso untuk mencatat pengguna.

Kami menggunakan AWS classic load balancers (ELB), AWS memberitahu kami bahwa tidak ada persistensi sesi pada ELB.

Apa yang saya coba cari tahu adalah bagaimana cookie bekerja dengan non-persistensi pada load balancers klasik.

DNS example.com diarahkan ke ELB. Ada 2 server di kolam Server1 dan Server2

Yang kami inginkan adalah jika pengguna mengklik beranda mereka di http://example.com/user/12345/katakan pada server 1 jika mereka belum login mereka diarahkan ke halaman sso http://example.com/user/login/sso, secara otomatis masuk dan mendapatkan cookie SESS<hexnumber>dan kemudian diarahkan kembali kehttp://example.com/user/12345/

Kami tidak diizinkan untuk menambahkan server sesi (redis) apa pun jaminan bahwa mereka akan tetap di server 1 untuk kedua pengalihan.

Setahu saya dengan setiap klik ke 'example.com' pengguna bisa berakhir di server 1 atau server 2.

Pertanyaan saya:

Jika mereka mendapatkan cookie di server1 dan kemudian dialihkan ke server2 bagaimana server2 tahu bahwa cookie sudah ditetapkan untuk pengguna itu di server1?

Sepertinya saya berpikir sendiri dalam lingkaran. Ketika mengerjakan jenis pengaturan ini di masa lalu menggunakan LBs tanpa ketekunan sesi, kami menggunakan server redis untuk mengadakan sesi dan setiap permintaan akan melihat redis sever untuk informasi sesi.

Cookie diatur di browser, bukan di server. Itu dibatasi untuk domain dan, secara opsional, jalur khusus di URL, sehingga selama kedua server diakses oleh domain yang sama, cookie akan ada di sana.

Jika cookie menunjuk ke suatu sesi, maka server1 dan server2 harus memiliki akses ke sesi tersebut dengan cara tertentu. Jika sesi tidak dapat dibagi antara server maka Anda harus memaksa pengguna untuk bertahan ke server tertentu. Ini dapat dengan mudah dilakukan dengan DNS dan sedikit sihir penulisan ulang URL:

• www.example.com menunjuk ke kedua server.
• www1.example.com hanya menunjuk ke server1
• www2.example.com hanya menunjuk ke server2

Menggunakan seperangkat aturan penulisan ulang sederhana (ish) dan cookie, pengguna kemudian dapat dikunci ke server tertentu, memastikan bahwa sesi-nya tetap ada.

Berikut ini beberapa detail lainnya.

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

Aturan penulisan ulang:

• cookie kegigihan: "backend"
• koneksi awal: "backend" tidak ditentukan, set "backend" ke www1 atau www2, tergantung pada server mana yang menjawab dan mengarahkan ke server itu. Cookie harus disetel ke domain "example.com", dengan cara ini akan dimuat di www1 dan www2
• Jika "backend" didefinisikan, pastikan nilainya sesuai dengan instance server dan redirect jika perlu.
• Pastikan bahwa cookie sesi didefinisikan dalam nama domain lengkap dari server - yaitu www1.example.com atau www2.example.com

Logika penulisan ulang harus didefinisikan di server web itu sendiri. Semua server web modern memiliki bahasa penulisan ulang yang sangat fitur yang benar-benar mampu menerapkan fungsi ini.

Jika Anda tidak dapat menggunakan database manajemen sesi seperti Elasticache Redis (Redis untuk sesi yang adil tidak boleh lebih dari $ 15 per bulan), maka opsi terbaik berikutnya adalah mengaktifkan sesi sticky pada ELB;

https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html

Ini akan memaksa pengguna untuk mengambil simpul backend yang sama sepanjang sesi. "Cookie yang dihasilkan penyeimbang muatan" dengan masa pakai 900 detik harus cukup baik tetapi Anda dapat mengubah ini.