Apakah Round-Robin DNS “cukup baik” untuk memuat konten statis?

Kami memiliki satu set konten statis bersama yang kami sajikan di antara situs web kami di http://sstatic.net . Sayangnya, konten ini sama sekali tidak memuat seimbang - konten ini dilayani dari satu server. Jika server itu memiliki masalah, semua situs yang bergantung padanya secara efektif turun karena sumber daya bersama adalah pustaka dan gambar javascript bersama yang penting.

Kami mencari cara untuk memuat keseimbangan konten statis di server ini, untuk menghindari ketergantungan server tunggal.

Saya menyadari bahwa round-robin DNS adalah solusi terbaik, low end (beberapa bahkan mungkin mengatakan ghetto ), tetapi saya tidak bisa tidak bertanya-tanya - apakah round robin DNS adalah solusi "cukup baik" untuk menyeimbangkan beban dasar konten statis ?

Ada beberapa diskusi tentang hal ini di tag [dns] [load-balancing] , dan saya telah membaca beberapa posting hebat tentang topik ini.

Saya mengetahui kelemahan umum dari penyeimbangan beban DNS melalui beberapa catatan round-robin A:

• biasanya tidak ada detak jantung atau deteksi kegagalan dengan catatan DNS, jadi jika server tertentu dalam rotasi turun, catatan A-nya harus dihapus secara manual dari entri DNS
• waktu untuk hidup (TTL) harus selalu ditetapkan cukup rendah agar ini berfungsi sama sekali, karena entri DNS di-cache secara agresif di seluruh internet
• komputer klien bertanggung jawab untuk melihat bahwa ada banyak catatan A dan memilih yang benar

Tetapi, apakah round robin DNS cukup baik sebagai starter, lebih baik daripada tidak sama sekali, "sementara kami meneliti dan menerapkan alternatif yang lebih baik" bentuk penyeimbangan beban untuk konten statis kami? Atau apakah round robin DNS sangat tidak berharga dalam kondisi apa pun ?

Jeff, saya tidak setuju, load balancing tidak menyiratkan redundansi, justru sebaliknya. Semakin banyak server yang Anda miliki, semakin besar kemungkinan Anda akan mengalami kegagalan pada saat tertentu. Itu sebabnya redundansi wajib dilakukan saat melakukan penyeimbangan muatan, tetapi sayangnya ada banyak solusi yang hanya menyediakan penyeimbangan muatan tanpa melakukan pemeriksaan kesehatan, sehingga menghasilkan layanan yang kurang andal.

DNS roundrobin sangat baik untuk meningkatkan kapasitas, dengan mendistribusikan beban di beberapa titik (berpotensi didistribusikan secara geografis). Tapi itu tidak memberikan kegagalan. Anda harus terlebih dahulu menjelaskan jenis kegagalan apa yang Anda coba tutupi. Kegagalan server harus dicakup secara lokal menggunakan mekanisme pengambilalihan alamat IP standar (VRRP, CARP, ...). Kegagalan sakelar ditutupi oleh tautan tangguh di server ke dua sakelar. Kegagalan tautan WAN dapat dicakup oleh pengaturan multi-tautan antara Anda dan penyedia Anda, baik menggunakan protokol perutean atau solusi layer2 (misalnya: PPP multi-tautan). Kegagalan situs harus ditanggung oleh BGP: alamat IP Anda direplikasi ke beberapa situs dan Anda mengumumkannya ke internet hanya jika tersedia.

Dari pertanyaan Anda, tampaknya Anda hanya perlu memberikan solusi server fail-over, yang merupakan solusi termudah karena tidak melibatkan perangkat keras maupun kontrak dengan ISP mana pun. Anda hanya perlu mengatur perangkat lunak yang sesuai pada server Anda untuk itu, dan sejauh ini solusi termurah dan paling dapat diandalkan.

Anda bertanya "bagaimana jika mesin haproxy gagal?". Itu sama. Semua orang yang saya kenal yang menggunakan haproxy untuk menyeimbangkan beban dan ketersediaan tinggi memiliki dua mesin dan menjalankan ucarp, disimpan atau detak jantung pada mereka untuk memastikan bahwa salah satu dari mereka selalu tersedia.

Semoga ini bisa membantu!

Sebagai load-balancing, ini ghetto tetapi lebih atau kurang efektif. Jika Anda memiliki satu server yang jatuh dari beban, dan ingin menyebarkannya ke beberapa server, itu mungkin menjadi alasan yang baik untuk melakukan ini, setidaknya untuk sementara.

Ada sejumlah kritik valid tentang round-robin DNS sebagai beban "balancing," dan saya tidak akan merekomendasikan melakukannya untuk itu selain sebagai bantuan band jangka pendek.

Tetapi Anda mengatakan motivasi utama Anda adalah untuk menghindari ketergantungan pada satu server. Tanpa cara otomatis mengeluarkan server mati dari rotasi, itu tidak terlalu berharga sebagai cara mencegah downtime. (Dengan cara otomatis menarik server dari rotasi dan TTL pendek, itu menjadi failover ghetto. Secara manual, bahkan bukan itu.)

Jika salah satu dari dua server bundar Anda rusak, maka 50% pelanggan Anda akan mengalami kegagalan. Ini lebih baik daripada kegagalan 100% dengan hanya satu server, tetapi hampir semua solusi lain yang melakukan failover nyata akan lebih baik dari ini.

Jika probabilitas kegagalan satu server adalah N, dengan dua server probabilitas Anda adalah 2N. Tanpa kegagalan otomatis yang cepat , skema ini meningkatkan kemungkinan bahwa beberapa pengguna Anda akan mengalami kegagalan.

Jika Anda berencana untuk mengeluarkan server mati dari rotasi secara manual, Anda dibatasi oleh kecepatan Anda dapat melakukan itu dan DNS TTL. Bagaimana jika server mati pada jam 4 pagi? Bagian terbaik dari kegagalan sebenarnya adalah tidur sepanjang malam. Anda sudah menggunakan HAProxy , jadi Anda harus terbiasa dengannya. Saya sangat menyarankan menggunakannya, karena HAProxy dirancang untuk situasi ini.

DNS round robin bukan seperti yang dipikirkan orang. Sebagai penulis perangkat lunak server DNS (yaitu, BIND ) kami mendapatkan pengguna yang bertanya-tanya mengapa round robin mereka berhenti bekerja sesuai rencana. Mereka tidak mengerti bahwa bahkan dengan TTL 0 detik akan ada sejumlah caching di luar sana, karena beberapa cache menempatkan waktu minimum (seringkali 30-300 detik) tidak peduli apa pun.

Juga, sementara server AUTH Anda mungkin melakukan round robin, tidak ada jaminan yang Anda pedulikan - cache yang diajak bicara oleh pengguna Anda - akan. Singkatnya, round robin tidak menjamin pemesanan dari sudut pandang klien, hanya apa yang disediakan server auth Anda ke cache.

Jika Anda ingin failover nyata, DNS hanyalah satu langkah. Bukan ide yang buruk untuk mendaftar lebih dari satu alamat IP untuk dua kelompok yang berbeda, tapi saya akan menggunakan teknologi lain di sana (seperti anycast sederhana) untuk melakukan penyeimbangan beban yang sebenarnya. Saya pribadi membenci perangkat keras yang menyeimbangkan beban perangkat keras dengan DNS karena biasanya salah. Dan jangan lupa DNSSEC akan datang, jadi jika Anda memilih sesuatu di area ini, tanyakan kepada vendor Anda apa yang terjadi ketika Anda menandatangani zona Anda.

Saya sudah mengatakannya beberapa kali sebelumnya, dan saya akan mengatakannya lagi - jika ketahanan adalah masalahnya maka trik DNS bukanlah jawabannya .

Sistem HA terbaik akan memungkinkan klien Anda untuk tetap menggunakan alamat IP yang sama persis untuk setiap permintaan. Ini adalah satu - satunya cara untuk memastikan bahwa klien tidak menyadari kegagalannya.

Jadi aturan dasarnya adalah bahwa ketahanan sejati membutuhkan tipuan tingkat routing IP . Gunakan alat penyeimbang beban, atau OSPF "multi-path biaya yang sama", atau bahkan VRRP.

DNS di sisi lain adalah teknologi pengalamatan . Itu ada hanya untuk memetakan dari satu namespace ke yang lain. Itu tidak dirancang untuk mengizinkan perubahan dinamis jangka pendek untuk pemetaan itu, dan karenanya ketika Anda mencoba untuk melakukan perubahan seperti itu, banyak klien yang tidak akan melihatnya, atau paling tidak akan membutuhkan waktu lama untuk melihatnya.

Saya juga akan mengatakan bahwa karena memuat bukan masalah bagi Anda, Anda mungkin juga memiliki server lain yang siap untuk dijalankan sebagai siaga panas. Jika Anda menggunakan round-robin bodoh Anda harus secara proaktif mengubah catatan DNS Anda ketika sesuatu rusak, jadi Anda mungkin juga secara proaktif membalik server siaga panas menjadi tindakan dan tidak mengubah DNS Anda.

Saya telah membaca semua jawaban dan satu hal yang tidak saya lihat adalah sebagian besar browser web modern akan mencoba salah satu alamat IP alternatif jika server tidak merespons. Jika saya ingat dengan benar maka Chrome bahkan akan mencoba beberapa alamat IP dan melanjutkan dengan server yang merespons terlebih dahulu. Jadi menurut saya DNS Round Robin Load balancing selalu lebih baik daripada tidak sama sekali.

BTW: Saya melihat DNS Round Robin lebih sebagai solusi distribusi beban sederhana.

Saya terlambat ke utas ini, jadi jawaban saya mungkin hanya akan melayang sendirian di bagian bawah, diabaikan, mengendus mengendus.

Pertama, jawaban yang benar untuk pertanyaan itu bukan untuk menjawab pertanyaan, tetapi untuk mengatakan:

1. "Kamu mungkin ingin Windows Network Load Balancing sebagai gantinya." ATAU
2. "Ikuti perkembangan zaman, tempatkan konten statis Anda pada sesuatu seperti Cloud Files atau S3 , dan miliki CDN mirror di seluruh dunia."

NLB sudah matang, cocok untuk tugas itu, dan cukup mudah diatur. Solusi cloud datang dengan pro dan kontra mereka sendiri, yang berada di luar ruang lingkup pertanyaan ini.

Pertanyaan

apakah round robin DNS cukup baik sebagai starter, lebih baik daripada tidak sama sekali, "sementara kami meneliti dan menerapkan alternatif yang lebih baik" bentuk penyeimbangan beban untuk konten statis kami?

Antara, katakanlah, 2 atau 3 server web statis? Ya, ini lebih baik daripada tidak sama sekali, karena ada penyedia DNS yang akan mengintegrasikan DNS Round Robin dengan pemeriksaan kesehatan server , dan untuk sementara waktu akan menghapus server mati dari catatan DNS. Jadi dengan cara ini Anda mendapatkan yang layak distribusi beban dan beberapa ketersediaan tinggi; dan semuanya membutuhkan waktu kurang dari 5 menit untuk mengatur.

Tetapi peringatan yang diuraikan oleh orang lain di utas ini berlaku:

• Peramban Microsoft saat ini menyimpan data DNS cache selama 30 menit , jadi Anda mencari waktu failover lebih dari 30 menit untuk subset dari pengguna Anda, tergantung pada status cache DNS awal mereka.
• Apa yang dilihat pengguna selama kegagalan dapat ... aneh (Anda tidak menggunakan auth pada konten statis, dan tentu saja tidak membentuk auth, tetapi tautan menunjukkan sesuatu yang harus diperhatikan).

Solusi lain

HAProxy fantastis, tetapi karena Stack Overflow ada di tumpukan teknologi Microsoft, mungkin menggunakan penyeimbangan beban Microsoft & alat ketersediaan tinggi akan memiliki lebih sedikit overhead admin. Network Load Balancing menangani satu bagian dari masalah, dan Microsoft sebenarnya memiliki L7 HTTP reverse proxy / load balancer sekarang.

Saya tidak pernah menggunakan ARR sendiri, tetapi mengingat itu pada rilis utama kedua, dan berasal dari Microsoft, saya menganggap itu sudah diuji dengan cukup baik. Ini memiliki dokumen yang mudah dipahami , berikut adalah bagaimana mereka melihat distribusi konten statis dan dinamis di webnodes, dan di sini adalah bagian tentang cara menggunakan ARR dengan NLB untuk mencapai distribusi beban dan ketersediaan tinggi.

Sungguh luar biasa berapa banyak kontributor yang membantu menyumbang informasi tentang DNS Round Robin sebagai mekanisme penyebaran dan ketahanan. Biasanya memang berhasil, tetapi Anda perlu memahami cara kerjanya, dan menghindari kesalahan yang disebabkan oleh semua informasi yang salah tersebut.

1) TTL pada catatan DNS yang digunakan untuk Round robin harus pendek - tetapi BUKAN NOL. Memiliki TTL di nol mematahkan cara utama ketahanan disediakan.

2) DNS RR menyebar, tetapi tidak menyeimbangkan beban, menyebar karena lebih dari basis klien yang besar, mereka cenderung untuk menanyakan server DNS secara independen, dan akhirnya berakhir dengan entri DNS pilihan pertama yang berbeda. Pilihan pertama yang berbeda itu berarti klien dilayani oleh server yang berbeda, dan bebannya tersebar. Tapi itu semua tergantung pada perangkat mana yang melakukan permintaan DNS, dan berapa lama hasilnya. Contoh umum adalah bahwa semua klien di belakang proksi perusahaan (yang melakukan permintaan DNS untuk mereka) semuanya akan berakhir dengan menargetkan server tunggal. Muatan tersebar - tetapi tidak seimbang secara merata.

3) DNS RR memberikan ketahanan selama perangkat lunak klien mengimplementasikannya dengan benar (dan TTL dan rentang perhatian pengguna tidak terlalu pendek). Ini karena DNS round robin menyediakan daftar alamat IP server yang terurut, dan perangkat lunak klien harus mencoba untuk menghubungi masing-masing alamat secara berurutan, hingga menemukan server yang menerima koneksi.

Jadi jika server pilihan pertama sedang down maka koneksi TCP / IP klien habis, dan asalkan TTL atau rentang perhatiannya tidak kadaluarsa, maka perangkat lunak klien melakukan upaya koneksi lain ke entri kedua dalam daftar - dan seterusnya hingga TTL kedaluwarsa, atau sampai ke akhir daftar (atau pengguna menyerah dengan jijik).

Daftar panjang server yang rusak (kesalahan Anda) dan batas coba lagi koneksi TCP / IP yang besar (Kesalahan konfigurasi klien) dapat dibuat untuk jangka waktu yang lama sebelum Klien benar-benar menemukan server yang berfungsi. TTL yang terlalu pendek berarti bahwa ia tidak pernah dapat berfungsi sampai akhir daftar, dan sebaliknya mengeluarkan permintaan DNS baru dan dilayani daftar baru (mudah-mudahan dalam urutan yang berbeda).

Kadang-kadang Klien mendapat sial dan daftar baru masih dimulai dengan server yang rusak. Untuk memberikan sistem kesempatan terbaik untuk memberikan ketahanan klien, Anda harus memastikan TTL lebih panjang dari rentang perhatian tipikal dan bagi klien untuk sampai ke bagian bawah daftar.

Setelah klien menemukan server yang berfungsi, ia harus mengingatnya, dan ketika perlu membuat koneksi berikutnya, ia tidak boleh mengulangi pencarian (kecuali TTL telah kedaluwarsa). TTL yang lebih lama mengurangi frekuensi pengguna mengalami penundaan sementara klien mencari server yang berfungsi - memberikan pengalaman yang lebih baik.

4) DNS TTL menjadi miliknya sendiri, ketika Anda ingin secara manual mengubah catatan DNS (misalnya untuk menghapus server rusak jangka panjang) maka TTL pendek memungkinkan perubahan itu untuk menyebar cepat (setelah Anda sempat melakukannya), jadi pertimbangkan keseimbangan antara berapa lama waktu yang diperlukan sebelum Anda tahu tentang masalah ini, dan buat perubahan manual - dan fakta bahwa klien normal hanya perlu melakukan pencarian baru untuk server yang berfungsi ketika TTL kedaluwarsa.

DNS round robin memiliki dua fitur luar biasa yang membuatnya sangat hemat biaya dalam berbagai skenario - pertama gratis, dan kedua hampir tersebar secara geografis seperti basis klien Anda.

Itu tidak memperkenalkan 'unit kegagalan' baru yang dilakukan oleh semua sistem 'pintar' lainnya. Tidak ada komponen tambahan yang bisa mengalami kegagalan umum dan simultan atas seluruh beban elemen yang saling terkait.

Sistem 'pintar' itu hebat dan memperkenalkan mekanisme luar biasa untuk mengoordinasikan dan memberikan keseimbangan tanpa batas dan kegagalan atas mekanisme, tetapi pada akhirnya metode yang mereka gunakan untuk memberikan bahwa pengalaman tanpa batas adalah kelemahan Achilles mereka - hal rumit tambahan yang bisa salah, dan ketika itu terjadi, akan memberikan pengalaman mulus dari kegagalan sistem yang luas.

Jadi YA, DNS round robin sudah pasti "cukup baik" untuk langkah pertama Anda di luar satu server yang menampung semua konten statis Anda di satu tempat.

Windows Vista & Windows 7 mengimplementasikan dukungan klien untuk round robin secara berbeda karena mereka meng-backport pemilihan alamat IPv6 ke IPv4. ( RFC 3484 )

Jadi, jika Anda memiliki sejumlah besar pengguna Vista, Windows 7, dan Windows 2008, Anda mungkin akan menemukan perilaku yang tidak konsisten dengan pemikiran yang Anda rencanakan dalam solusi penyeimbangan beban Anda.

Saya selalu menggunakan Round-Robin DNS, dengan TTL panjang, sebagai load-balancer. Ini berfungsi sangat baik untuk layanan HTTP / HTTPS dengan browser .

Saya benar-benar stres dengan peramban karena sebagian besar peramban menerapkan semacam «coba lagi pada IP lain», tetapi saya tidak tahu bagaimana perpustakaan atau perangkat lunak lain menangani solusi IP ganda.

Ketika browser tidak mendapatkan balasan dari satu server, maka secara otomatis akan memanggil IP berikutnya, dan kemudian bertahan dengan itu (sampai turun ... dan kemudian mencoba yang lain).

Kembali pada tahun 2007, saya telah melakukan tes berikut:

• tambahkan iframe di situs web saya, menunjuk ke satu entri Round-Robin, seperti http://roundrobin.test:10080/ping.php
• halaman dilayani oleh 3 soket PHP, mendengarkan pada 3 perbedaan IP, semua pada port 10080 (saya tidak mampu untuk menguji pada port 80, karena situs web saya berjalan di atasnya)
• satu soket (katakanlah A ) ada di sana untuk memeriksa bahwa browser dapat terhubung pada port 10080 (karena banyak perusahaan hanya mengizinkan port standar)
• dua soket lainnya (misalnya B dan C ) dapat diaktifkan atau dinonaktifkan dengan cepat.

Saya biarkan berjalan satu jam, punya banyak data. Hasilnya adalah bahwa untuk 99,5% hit pada socket A , saya mendapat hit pada socket B atau C (tentu saja saya tidak menonaktifkan keduanya pada saat yang sama). Peramban adalah: iPhone, Chrome, Opera, MSIE 6/7/8, BlackBerry, Firefox 3 / 3.5 ... Peramban yang bahkan tidak memenuhi standar pun melakukannya dengan benar!

Sampai hari ini, saya tidak pernah mengujinya lagi, tapi mungkin saya akan menyiapkan tes baru suatu hari atau merilis kode pada github sehingga orang lain dapat mengujinya.

Catatan penting: bahkan jika itu berfungsi sebagian besar waktu, itu tidak menghilangkan fakta bahwa beberapa permintaan akan gagal. Saya juga menggunakannya untuk permintaan POST, karena aplikasi saya akan mengembalikan pesan kesalahan jika tidak berfungsi, sehingga pengguna dapat mengirim data lagi, dan kemungkinan besar browser akan menggunakan IP lain dalam kasus ini dan simpan akan berfungsi . Dan untuk konten statis, ini berfungsi sangat bagus.

Jadi jika Anda bekerja dengan browser, gunakan Round-Robin DNS, baik untuk konten statis atau dinamis, Anda akan lebih baik. Server juga dapat turun di tengah transaksi, dan bahkan dengan penyeimbang beban terbaik Anda tidak dapat menangani kasus seperti itu. Untuk konten dinamis, Anda harus membuat sesi / database / file Anda sinkron, kalau tidak Anda tidak akan bisa menangani ini (tapi itu juga berlaku dengan penyeimbang beban nyata).

Catatan tambahan: Anda dapat menguji perilaku menggunakan IP Anda sendiri iptables. Misalnya, sebelum aturan firewall Anda untuk lalu lintas HTTP, tambahkan:

iptables -A INPUT -p tcp --dport 80 --source 12.34.56.78 -j REJECT

(di mana 12.34.56.78jelas IP Anda)

Jangan gunakan DROP, karena meninggalkan port yang difilter , dan browser Anda akan menunggu sampai waktu habis. Jadi sekarang, Anda dapat mengaktifkan atau menonaktifkan satu server atau yang lain. Tes yang paling jelas adalah untuk menonaktifkan server A, memuat halaman, lalu mengaktifkan server A dan menonaktifkan server B. Ketika Anda akan memuat halaman lagi, Anda akan melihat sedikit menunggu dari browser, maka itu akan memuat dari server Lagi. Di Chrome, Anda dapat mengonfirmasi IP server dengan melihat permintaan di panel jaringan. Di Generaltab Headers, Anda akan melihat tajuk palsu bernama Remote Address:. Ini adalah IP dari mana Anda mendapat jawaban.

Jadi, jika Anda perlu masuk dalam mode pemeliharaan di satu server, cukup nonaktifkan lalu lintas HTTP / HTTPS dengan satu iptables REJECTaturan, semua permintaan akan masuk ke server lain (dengan sekali menunggu, hampir tidak terlihat bagi pengguna).

Saya tidak berpikir itu adalah solusi yang cukup baik karena katakanlah Anda memiliki dua server sekarang dan Anda round robin menggunakan DNS ke setiap alamat IP server. Ketika satu server turun, server DNS tidak memiliki pengetahuan bahwa itu turun dan akan terus melayani alamat IP itu, sebagai bagian dari proses RR. Kemudian 50% audiens Anda akan mendapatkan situs yang rusak karena kehilangan javascript atau gambar.

Mungkin lebih mudah untuk menunjuk ke alamat IP umum yang ditangani oleh Windows NLB yang mewakili dua server di belakang. Kecuali Anda menggunakan server Linux untuk konten statis Anda, apakah saya ingat pernah membaca itu di suatu tempat?

Perimbangan beban round-robin hanya berfungsi ketika Anda juga mengendalikan Zona DNS sehingga Anda dapat mengubah daftar server dan mendorongnya ke master zona secara tepat waktu.

Seperti disebutkan dalam salah satu jawaban lain, kejahatan tersembunyi round-robin adalah caching DNS yang dapat terjadi di mana saja antara server Anda dan klien yang sepenuhnya meniadakan manfaat kecil dari solusi ini. Bahkan dengan DNS TTL yang diatur ke nilai yang sangat rendah, Anda memiliki sedikit kendali atas berapa lama ISP atau bahkan cache DNS klien akan membuat alamat IP yang sudah mati aktif.

Ini merupakan peningkatan dari SPOF pasti, tetapi hanya marjinal. Saya akan melihat siapa yang meng-hosting server Anda dan melihat apa yang mereka tawarkan, banyak yang memiliki semacam layanan penyeimbang beban dasar yang dapat mereka berikan.

Anda mungkin juga memiliki satu server dengan konten statis yang diduplikasi dalam S3 dan beralih ke S3 CNAME ketika primer Anda turun. Anda akan berakhir dengan penundaan yang sama tetapi tanpa biaya server ganda.

Ini benar-benar tergantung pada apa yang Anda bicarakan dan berapa banyak server yang Anda putar. Saya pernah punya situs yang berjalan di beberapa server, dan saya menggunakan DNS round robin karena sebagian besar pemula saya saat itu, dan itu sebenarnya bukan masalah besar. Itu bukan masalah besar karena itu tidak crash. Itu adalah sistem yang tidak rumit yang benar-benar bodoh, jadi ia bertahan, dan memiliki tingkat lalu lintas yang cukup konstan. Jika memang macet karena macet, itu siang hari dan sesuatu yang bisa saya tangani dengan mudah. Saya akan mengatakan konten statis Anda memenuhi syarat cukup sederhana untuk tidak menyebabkan crash sendiri.

Di luar kegagalan perangkat keras, dll., Seberapa stabil server Anda? Berapa "lonjakan" lalu lintas Anda di konten ini? Dengan asumsi langsung Apache atau sesuatu dan lalu lintas yang relatif datar, itu tidak akan banyak crash, dan saya akan mengatakan round-robin "cukup baik".

Saya yakin saya akan memilih karena saya tidak mengajarkan solusi HA 100%, tapi bukan itu yang Anda minta. Itu tergantung pada apa yang Anda bersedia terima sebagai solusi vs upaya yang dihabiskan.

Jika Anda menggunakan RR DNS untuk load balancing, itu akan baik-baik saja, tetapi Anda tidak melakukannya. Anda menggunakannya untuk mengaktifkan server yang berlebihan, dalam hal ini tidak baik.

Seperti yang dikatakan posting sebelumnya, Anda perlu sesuatu untuk mendeteksi detak jantung dan berhenti memukulnya sampai kembali.

Berita baiknya adalah detak jantung tersedia dengan sangat murah, baik di sakelar atau di Windows.

Entah tentang OS lain tapi saya menganggap itu ada di sana juga.

Saya sarankan Anda menetapkan alamat IP tambahan untuk masing-masing server Anda (selain IP statis yang Anda gunakan untuk, katakanlah, ssh), dan Anda bawa ke kolam DNS. Dan kemudian Anda menggunakan beberapa perangkat lunak untuk beralih di sekitar alamat IP ini jika server gagal. Detak jantung atau CARP dapat melakukan itu, misalnya, tetapi ada solusi lain di luar sana.

Ini memiliki keuntungan bahwa untuk klien layanan Anda, tidak ada yang harus diubah dalam pengaturan, dan Anda tidak perlu khawatir tentang caching DNS atau TTL, tetapi Anda masih dapat mengambil keuntungan dari round-robin DNS round-robin "load balancing" .

Ini mungkin akan melakukan pekerjaan, terutama jika Anda dapat memiliki beberapa IP di kotak statis Anda. punya satu IP "sajikan konten statis" dan satu IP "kelola mesin". Jika sebuah kotak kemudian turun, Anda bisa menggunakan solusi HA yang ada atau intervensi manual untuk membawa IP dari mesin yang gagal naik ke salah satu dari "anggota cluster" yang lain atau mesin yang sama sekali baru (tergantung pada seberapa cepat akan menjadi untuk mengaktifkan dan menjalankannya).

Namun, solusi semacam itu akan memiliki beberapa masalah kecil. Penyeimbangan beban tidak akan mendekati sempurna dan jika Anda mengandalkan intervensi manual, Anda mungkin mengalami gangguan pada beberapa pengunjung.

Sebuah penyeimbang beban perangkat keras mungkin dapat melakukan pekerjaan yang lebih baik dari berbagi beban dan menyediakan "waktu kerja cluster" daripada DNS round-robin. Di sisi lain, itu adalah satu (atau dua, karena idealnya Anda memiliki LBs dalam kelompok HA) perangkat keras yang perlu membeli, daya dan pendinginan dan (mungkin) beberapa waktu untuk berkenalan (jika Anda belum memiliki penyeimbang beban khusus).

Untuk ringkas menjawab pertanyaan (adalah round robin DNS cukup baik sebagai starter, lebih baik daripada tidak, "sementara kita meneliti dan menerapkan alternatif yang lebih baik" bentuk load balancing untuk konten statis kita?), Saya akan mengatakan bahwa itu adalah lebih baik daripada tidak, tetapi Anda harus terus meneliti bentuk lain dari load balancing.

Ketika meneliti Windows Load Balancing beberapa tahun yang lalu, saya melihat sebuah dokumen yang menyatakan bahwa web farm Microsoft dikonfigurasikan sebagai beberapa kelompok penyeimbang beban, dengan round round DNS di antaranya. Karena Anda dapat memiliki beberapa server DNS merespons di setiap namespace, dan karena penyeimbangan beban Microsoft adalah penyembuhan sendiri, ini memberikan redundansi dan penyeimbangan beban.

Kelemahan: Anda memerlukan setidaknya 4 server (2 server x 2 grup).

Menjawab komentar Jeff pada jawaban Schof, apakah ada cara untuk DNS round-robin antara server HAProxy?

Ini memiliki penggunaan yang sangat marjinal, cukup untuk membantu Anda ketika Anda menempatkan solusi nyata di tempat. Seperti yang Anda katakan, TTL harus disetel cukup rendah. Namun, ini memiliki keuntungan sampingan, yaitu mengeluarkan mesin yang bermasalah dari DNS saat mengalami masalah. Katakanlah Anda memiliki SvrA, SvrB, dan SvrC membagikan konten Anda dan SvrA turun. Anda menariknya dari DNS dan setelah periode waktu singkat yang ditentukan oleh TTL rendah Anda, resolver akan mencari server yang berbeda (SvrB atau SvrC) yang naik. Anda mendapatkan SvrA kembali online dan memasukkannya kembali ke DNS. Downtime singkat untuk beberapa orang, tidak untuk orang lain. Tidak hebat, tapi bisa diterapkan. Semakin banyak server statis yang Anda masukkan ke dalam campuran, semakin kecil kemungkinan Anda untuk memiliki kelompok mayoritas pengguna.

Anda tentu tidak akan mendapatkan distribusi seimbang yang sebenarnya yang akan disediakan oleh solusi penyeimbangan beban karena topologi Internet. Saya masih menonton beban di semua server yang terlibat.