Beberapa pusat data dan lalu lintas HTTP: DNS Round Robin adalah HANYA cara untuk memastikan kegagalan instan?

Beberapa catatan A menunjuk ke domain yang sama tampaknya digunakan hampir secara eksklusif untuk menerapkan DNS Round Robin sebagai teknik penyeimbangan beban yang murah.

Peringatan biasa terhadap DNS RR adalah bahwa itu tidak baik untuk ketersediaan tinggi. Ketika 1 IP turun, klien akan terus menggunakannya selama beberapa menit.

Penyeimbang beban sering disarankan sebagai pilihan yang lebih baik.

Kedua klaim tersebut tidak sepenuhnya benar:

1. Ketika lalu lintas adalah HTTP, sebagian besar browser HTML dapat secara otomatis mencoba catatan A berikutnya jika sebelumnya turun, tanpa pencarian DNS baru. Baca di sini bab 3.1 dan di sini .

2. Ketika beberapa pusat data dilibatkan, DNS RR adalah satu-satunya opsi untuk mendistribusikan lalu lintas lintasnya.

Jadi, apakah benar bahwa, dengan beberapa pusat data dan lalu lintas HTTP, penggunaan DNS RR adalah cara HANYA untuk memastikan kegagalan instan saat satu pusat data turun?

Terima kasih,

Valentino

Sunting:

• Tentu saja setiap pusat data memiliki Load Balancer lokal dengan cadangan panas.
• Tidak masalah untuk mengorbankan afinitas sesi untuk kegagalan instan.
• AFAIK satu-satunya cara bagi DNS untuk menyarankan pusat data alih-alih yang lain adalah membalas dengan hanya IP (atau IP) yang terkait dengan pusat data itu. Jika pusat data menjadi tidak terjangkau maka semua IP tersebut juga tidak dapat dijangkau. Ini berarti bahwa, bahkan jika browser HTML yang cerdas dapat langsung mencoba catatan A lainnya, semua upaya akan gagal sampai entri cache lokal berakhir dan pencarian DNS baru selesai, mengambil IP yang berfungsi baru (Saya menganggap DNS secara otomatis menyarankan kepada pusat data baru ketika salah satu gagal). Jadi, "DNS pintar" tidak dapat memastikan kegagalan instan.
• Sebaliknya, round-robin DNS mengizinkannya. Ketika satu pusat data gagal, peramban HTML yang pintar (kebanyakan dari mereka) langsung mencoba yang lain yang direkam dalam cache yang melompat ke pusat data yang lain (berfungsi). Jadi, round-robin DNS tidak menjamin afinitas sesi atau RTT terendah tetapi tampaknya merupakan satu-satunya cara untuk memastikan kegagalan instan saat klien menggunakan browser HTML "pintar".

Edit 2:

• Beberapa orang menyarankan TCP Anycast sebagai solusi definitif. Dalam makalah ini (bab 6) dijelaskan bahwa kegagalan-kegagalan Anycast terkait dengan konvergensi BGP. Untuk alasan ini, Anycast dapat digunakan dari 15 menit hingga 20 detik untuk menyelesaikannya. 20 detik dimungkinkan pada jaringan di mana topologi dioptimalkan untuk ini. Mungkin hanya operator CDN yang dapat memberikan kegagalan yang cepat tersebut.

Edit 3: *

• Saya melakukan beberapa pencarian dan penelusuran DNS (mungkin beberapa pakar dapat memeriksa ulang) dan:
  • Satu-satunya CDN yang menggunakan TCP Anycast tampaknya adalah CacheFly, operator lain seperti jaringan CDN dan BitGravity menggunakan CacheFly. Tampaknya ujung-ujungnya tidak dapat digunakan sebagai proksi terbalik. Oleh karena itu, mereka tidak dapat digunakan untuk memberikan failover instan.
  • Akamai dan LimeLight tampaknya menggunakan DNS geo-aware. Tapi! Mereka mengembalikan beberapa catatan A. Dari traceroutes tampaknya IP yang dikembalikan berada di pusat data yang sama. Jadi, saya bingung bagaimana mereka bisa menawarkan 100% SLA ketika satu pusat data turun.

Ketika saya menggunakan istilah "DNS Round Robin" yang saya maksud secara umum adalah "teknik penyeimbangan beban murah" seperti yang dijelaskan OP.

Tapi itu bukan satu-satunya cara DNS dapat digunakan untuk ketersediaan tinggi global. Biasanya, sulit bagi orang dengan latar belakang (teknologi) yang berbeda untuk berkomunikasi dengan baik.

Teknik load balancing terbaik (jika uang tidak menjadi masalah) umumnya dianggap sebagai:

1. Jaringan global server DNS 'cerdas' Anycast,
2. dan satu set pusat data yang tersebar secara global,
3. di mana setiap node DNS mengimplementasikan Split Horizon DNS,
4. dan pemantauan ketersediaan dan arus lalu lintas tersedia untuk node DNS 'cerdas' dalam beberapa cara,
5. sehingga permintaan DNS pengguna mengalir ke server DNS terdekat melalui IP Anycast ,
6. dan server DNS ini membagikan Rekaman A rendah TTL / set A Records untuk pusat data terdekat / terbaik untuk pengguna akhir ini melalui DNS horizon split 'cerdas'.

Menggunakan anycast untuk DNS umumnya baik-baik saja, karena respons DNS tidak memiliki kewarganegaraan dan hampir sangat singkat. Jadi jika rute BGP berubah, sangat tidak mungkin untuk mengganggu permintaan DNS.

Anycast kurang cocok untuk percakapan HTTP yang lebih lama dan stateful, sehingga sistem ini menggunakan split horizon DNS. Sesi HTTP antara klien dan server disimpan ke satu pusat data; umumnya tidak bisa gagal ke pusat data lain tanpa merusak sesi.

Seperti yang saya ditunjukkan dengan "set A Records" apa yang saya sebut 'DNS Round Robin' dapat digunakan bersama dengan pengaturan di atas. Ini biasanya digunakan untuk menyebarkan beban lalu lintas ke beberapa penyeimbang beban yang sangat tersedia di setiap pusat data (sehingga Anda bisa mendapatkan redundansi yang lebih baik, gunakan penyeimbang beban yang lebih kecil / lebih murah, tidak membanjiri buffer jaringan Unix dari satu server host, dll).

Jadi, apakah benar bahwa, dengan beberapa pusat data dan lalu lintas HTTP, penggunaan DNS RR adalah cara HANYA untuk memastikan ketersediaan tinggi?

Tidak, itu tidak benar, tidak jika dengan 'DNS Round Robin' yang kami maksudkan adalah membagikan banyak catatan A untuk suatu domain. Tapi memang benar bahwa penggunaan DNS yang cerdas adalah komponen penting dalam sistem ketersediaan tinggi global. Di atas menggambarkan satu cara umum (sering kali terbaik) untuk pergi.

Sunting: Makalah Google "Bergerak Melampaui Informasi Jalur End-to-End untuk Mengoptimalkan Kinerja CDN" bagi saya tampaknya merupakan yang terdepan dalam distribusi beban global untuk kinerja pengguna akhir terbaik.

Sunting 2: Saya membaca artikel "Mengapa Berbasis DNS .. GSLB .. Tidak Bekerja" yang ditautkan oleh OP, dan ini adalah ikhtisar yang bagus - Saya sarankan melihatnya. Baca dari atas.

Di bagian "Solusi untuk masalah caching browser" itu menganjurkan tanggapan DNS dengan beberapa A Records menunjuk ke beberapa pusat data sebagai satu-satunya solusi yang mungkin untuk kegagalan seketika berakhir.

Di bagian "Menyiramnya turun" di dekat bagian bawah, itu memperluas pada yang jelas, bahwa mengirim beberapa Catatan A tidak keren jika mereka menunjuk ke pusat data di beberapa benua, karena klien akan terhubung secara acak dan dengan demikian cukup sering mendapatkan 'lambat' DC di benua lain. Dengan demikian agar ini bekerja dengan sangat baik, banyak pusat data di setiap benua diperlukan.

Ini adalah solusi yang berbeda dari langkah saya 1 - 6. Saya tidak dapat memberikan jawaban yang sempurna mengenai hal ini, saya pikir diperlukan spesialis DNS dari orang-orang seperti Akamai atau Google, karena banyak dari ini bermuara pada pengetahuan praktis tentang keterbatasan cache DNS dan browser yang digunakan saat ini. AFAIK, langkah 1-6 saya adalah apa yang Akamai lakukan dengan DNS mereka (adakah yang bisa mengkonfirmasi ini?).

Perasaan saya - yang berasal dari bekerja sebagai PM di portal peramban seluler (ponsel) - adalah bahwa keragaman dan tingkat kerusakan total peramban di luar sana luar biasa. Saya pribadi tidak akan mempercayai solusi HA yang mengharuskan terminal pengguna akhir untuk 'melakukan hal yang benar'; jadi saya percaya bahwa kegagalan seketika global berakhir tanpa istirahat sesi tidak layak hari ini.

Saya pikir langkah 1-6 saya di atas adalah yang terbaik yang tersedia dengan teknologi komoditas. Solusi ini tidak mengalami kegagalan sesaat.

Saya ingin salah satu spesialis DNS dari Akamai, Google dll untuk datang dan membuktikan saya salah. :-)

Pertanyaan Anda adalah: "Apakah DNS Round Robin HANYA cara untuk memastikan kegagalan instan?"

Jawabannya adalah: "DNS Round Robin TIDAK PERNAH cara yang tepat untuk memastikan kegagalan-instan instan".

(setidaknya tidak dengan sendirinya)

Cara yang tepat untuk mencapai fail-over instan adalah dengan menggunakan perutean BGP4 sehingga kedua situs menggunakan alamat IP yang sama. Dengan menggunakan ini, teknologi perutean inti internet digunakan untuk merutekan permintaan ke pusat data yang tepat, alih-alih menggunakan teknologi pengalamatan inti internet .

Dalam konfigurasi paling sederhana ini hanya menyediakan fail-over. Itu juga dapat digunakan untuk menyediakan Anycast, dengan peringatan bahwa protokol berbasis TCP akan gagal pada saat peralihan jika ada ketidakstabilan dalam perutean.

Jadi, apakah benar bahwa, dengan beberapa pusat data dan lalu lintas HTTP, penggunaan DNS RR adalah cara HANYA untuk memastikan ketersediaan tinggi?

Jelas itu adalah klaim yang salah - Anda hanya perlu melihat Google, Akamai, Yahoo, untuk melihat bahwa mereka tidak menggunakan respons round-robin [*] sebagai satu-satunya solusi mereka (beberapa mungkin menggunakannya sebagian, bersama dengan pendekatan lain .)

Ada banyak pilihan yang mungkin, tetapi itu benar-benar tergantung pada kendala apa yang Anda miliki, dengan layanan / aplikasi yang Anda pilih.

Dimungkinkan untuk menggunakan teknik round-robin pada pendekatan server yang sederhana, co-located, dan tidak perlu khawatir tentang kegagalan server, jika Anda juga mengatur 'kegagalan' dari alamat IP. (Tetapi sebagian besar memilih teknik penyeimbangan beban, satu alamat IP, dan kegagalan-antara penyeimbang beban).

Mungkin Anda memerlukan semua permintaan untuk satu sesi untuk pergi ke server yang sama, tetapi Anda ingin agar permintaan tersebar di berbagai cluster server regional? Round robin tidak tepat, untuk itu: Anda perlu melakukan sesuatu yang memastikan setiap klien tertentu mengakses cluster server fisik yang sama setiap kali (kecuali ketika 'pengecualian' terjadi, seperti kegagalan server). Entah mereka menerima alamat IP yang konsisten dari permintaan DNS, atau diarahkan ke cluster server fisik yang sama. Solusi untuk itu termasuk berbagai "load balancers" DNS komersial dan non-komersial, atau (jika Anda memiliki kontrol lebih besar terhadap jaringan Anda) iklan jaringan BGP. Anda dapat mengatur server nama domain Anda sendiri untuk memberikan tanggapan yang sama sekali berbeda (tetapi, karena permintaan DNS dapat dikirim ke semua tempat, Anda tidak akan

[* Saya akan menggunakan "round-robin", karena 'RR' dalam terminologi DNS berarti "catatan sumber daya".]

Pengamatan vmiazzo +1 yang sangat bagus untuk Anda !! Saya terjebak persis di mana Anda berada .. bingung dengan bagaimana CDN ini melakukan keajaiban mereka.

Berikut ini adalah tebakan saya tentang bagaimana CDN menjalankan jaringan mereka:

• Gunakan DNS Anycast (disebutkan oleh Jesper Mortensen) untuk mendapatkan pusat data terdekat
• Mereka menjalankan jaringan lokal yang menjangkau berbagai pusat data yang memungkinkan mereka melakukan sesuatu seperti CARP pada host mereka di seluruh pusat data yang berbeda

Atau

• Mereka menggunakan Gateway Load Balancing Protocol pada router mereka atau Hot Standby Router Protocol (HSRP) . yang berurusan dengan pemadaman data pusat.
• Alasan mereka memasukkan beberapa IP adalah agar klien akan mencoba lagi, dan pada saat klien mencoba lagi, jalur perutean mungkin telah berubah.

Saat ini solusi berikut berfungsi untuk saya: - DNS mengembalikan beberapa IP, misalnya:

www -> CNAME www1 , www1 A -> 123.123.123.1
www -> CNAME www2 , www2 A -> 123.123.123.1 
www -> CNAME www3 , www3 A -> 123.123.123.1 
                    www3 A -> 8.4.56.7 <--- reverse proxy

• Titik masuk terakhir ke proxy terbalik di amazon cloud, yang secara cerdas diteruskan ke server yang tersedia (atau sediakan di bawah halaman pemeliharaan)

Proxy terbalik masih tertabrak tetapi tidak seberat yang utama.

Mengapa RFC 2782 (berlaku sama dengan MX / prioritas untuk layanan seperti http, imap, ...) tidak diterapkan di semua jenis browser? Segalanya akan lebih mudah ... Ada bug tentang, dibuka selama sepuluh tahun di Mozilla !!! karena itu akan menjadi akhir dari industri penyeimbang beban komersial ??? Saya sangat kecewa tentang itu.

2 - Anda dapat melakukan ini dengan Anycast menggunakan Quagga

(Bahkan jika ada beberapa info bahwa Anycast buruk dengan TCP ada beberapa perusahaan besar yang menggunakannya seperti CacheFly)

Saya bertanya-tanya berapa banyak orang yang menjawab pertanyaan-pertanyaan ini yang sebenarnya menjalankan jaringan server besar di seluruh dunia? Google menggunakan round robin dan perusahaan saya telah menggunakannya selama bertahun-tahun. Ini dapat bekerja dengan cukup baik, dengan beberapa batasan. Ya, itu perlu ditambah dengan langkah-langkah lain.

Kunci sebenarnya adalah bersedia menerima satu atau dua cegukan jika server rusak. Ketika saya menarik steker di server, jika browser mencoba mengakses server itu, akan ada penundaan sekitar satu menit saat browser mengetahui bahwa alamat IP sedang down. Tetapi kemudian pergi ke server lain dengan sangat cepat.

Ini bekerja dengan baik, dan orang-orang yang mengklaim bahwa itu menyebabkan banyak masalah tidak tahu apa yang mereka bicarakan. Itu hanya membutuhkan desain yang tepat.

Kegagalan menyebalkan. HA terbaik menggunakan semua sumber daya sepanjang waktu.

Saya telah bekerja dengan HA sejak 1986. Saya menjalani pelatihan ekstensif untuk membuat sistem failover dan saya sama sekali bukan penggemar failover.

Selain itu, RR memang berfungsi untuk mendistribusikan beban, meskipun secara pasif dan bukan secara aktif. Log server kami dengan jelas menunjukkan persentase lalu lintas yang sesuai pada setiap server - dengan alasan.

Pilihan lain yang sangat sederhana adalah menggunakan TTL rendah (seberapa rendah tergantung pada kebutuhan Anda) dalam catatan DNS A atau CNAME dan memperbarui catatan ini untuk memilih IP mana yang akan digunakan.

Kami memiliki 2 ISP dan beberapa layanan publik dan kami berhasil menggunakan metode ini untuk ketersediaan tinggi dari 3 tahun.

Salah satu spanner dalam karya ini adalah bahwa sejumlah ISP memiliki resolver yang dikonfigurasi dengan buruk yang merekam cache untuk interval yang ditetapkan dan sepenuhnya mengabaikan pengaturan TTL. Seharusnya tidak begitu dan tidak ada alasan untuk itu, tetapi sayangnya dari pengalaman saya dengan bermigrasi banyak situs web dan layanan itu memang terjadi.

TCP Anycast sebenarnya sangat stabil dan digunakan setidaknya oleh CacheFly (sejak 2002), Prolexic dan BitGravity. Presentasi yang baik tentang TCP Anycast dilakukan di NANOG 37: http://198.108.95.21/meetings/nanog37/presentations/matt.levine.pdf

Catatan berganda adalah satu-satunya cara untuk menghilangkan satu titik kegagalan. Solusi lain memaksa semua permintaan masuk untuk melalui satu perangkat di suatu tempat antara server dan klien.

Jadi untuk redundansi absolut, itu perlu. Itulah sebabnya google melakukannya, atau siapa pun yang ingin diyakinkan tentang ketersediaan layanan berkelanjutan.

Cukup jelas mengapa hal ini terjadi ... beberapa catatan A adalah satu-satunya cara untuk memindahkan titik di mana permintaan dialihkan ke browser klien. Metode lain mana pun akan bergantung pada satu titik antara browser klien dan server di mana kegagalan dapat terjadi, menurunkan layanan Anda. Dengan menggunakan catatan A, satu-satunya titik kegagalan dari klien ke server menjadi klien itu sendiri.

Jika Anda tidak memiliki beberapa pengaturan catatan A, Anda meminta waktu henti ...

Metode ini jelas tidak bisa diandalkan untuk load balancing.