Pertanyaan pengaturan ketersediaan tinggi global


10

Saya memiliki dan mengoperasikan visualwebsiteoptimizer.com /. Aplikasi ini menyediakan cuplikan kode yang dimasukkan oleh pelanggan saya di situs web mereka untuk melacak metrik tertentu. Karena cuplikan kode adalah JavaScript eksternal (di bagian atas kode situs), sebelum menampilkan situs web pelanggan, browser pengunjung menghubungi server aplikasi kami. Jika server aplikasi kami mogok, browser akan terus berusaha membuat koneksi sebelum waktu habis (biasanya 60 detik). Seperti yang dapat Anda bayangkan, kami tidak dapat menurunkan server aplikasi kami dalam skenario apa pun karena itu akan berdampak negatif pada pengalaman tidak hanya pengunjung situs web kami tetapi juga pengunjung situs web pelanggan kami!

Kami saat ini menggunakan mekanisme DNS failover dengan satu server cadangan yang terletak di pusat data yang berbeda (benua yang sebenarnya berbeda). Yaitu, kami memantau server aplikasi kami dari 3 lokasi terpisah dan segera setelah terdeteksi turun, kami mengubah catatan untuk menunjuk ke cadangan IP server. Ini berfungsi dengan baik untuk sebagian besar browser (karena TTL kami adalah 2 menit) tetapi IE cache DNS selama 30 menit yang mungkin merupakan pembunuh bayaran. Lihat posting terbaru kami dari visualwebsiteoptimizer.com/split-testing-blog/maximum-theoretical-downtime-for-a-website-30-minutes/

Jadi, pengaturan seperti apa yang dapat kita gunakan untuk memastikan kegagalan yang hampir instan jika pusat data aplikasi mengalami pemadaman besar? Saya baca di sini www.tenereillo.com/GSLBPageOfShame.htm bahwa memiliki banyak catatan A adalah solusi tetapi kami tidak dapat melakukan sinkronisasi sesi (belum). Strategi lain yang kami jelajahi adalah memiliki dua catatan A, satu menunjuk ke server aplikasi dan yang kedua ke proxy terbalik (terletak di pusat data yang berbeda) yang memutuskan ke server aplikasi utama jika terserah dan untuk mem-backup server jika terserah. Apakah menurut Anda strategi ini masuk akal?

Untuk memastikan prioritas kami, kami dapat menjaga situs web atau aplikasi kami tetap rendah tetapi kami tidak dapat membiarkan situs web pelanggan melambat karena waktu henti kami. Jadi, seandainya server aplikasi kami tidak berfungsi, kami tidak bermaksud merespons dengan respons aplikasi default. Bahkan tanggapan kosong akan cukup, kita hanya perlu browser menyelesaikan koneksi HTTP itu (dan tidak ada yang lain).

Referensi: Saya membaca utas ini yang berguna serverfault.com/questions/69870/multiple-data-centers-and-http-traffic-dns-round-robin-is-the-only-way-to-ureure

Jawaban:


6

Situasi Anda cukup mirip dengan kita. Kami ingin membagi pusat data, dan jenis kegagalan jaringan-lapisan.

Jika Anda memiliki anggaran untuk melakukannya, maka yang Anda inginkan adalah dua pusat data, beberapa IP transit untuk masing-masing, sepasang router tepi yang melakukan sesi BGP ke penyedia transit Anda, mengiklankan alamat IP Anda ke internet global.

Ini adalah satu-satunya cara untuk melakukan failover sejati. Ketika router memperhatikan bahwa rute ke server Anda tidak lagi valid (yang dapat Anda lakukan dalam beberapa cara), maka mereka berhenti mengiklankan rute itu, dan lalu lintas masuk ke situs lain.

Masalahnya adalah, bahwa untuk sepasang router tepi, Anda mencari biaya yang cukup tinggi pada awalnya untuk mendapatkan pengaturan ini.
Maka Anda perlu mengatur jaringan di balik semua ini, dan Anda mungkin ingin mempertimbangkan semacam konektivitas Layer2 antara situs Anda sebagai tautan point-to-point sehingga Anda akan memiliki kemampuan untuk merutekan lalu lintas yang masuk ke satu pusat data, langsung ke yang lain jika terjadi kegagalan sebagian dari situs utama Anda.

Praktik terbaik Bih Multihomed / Multi-lokasi dan Cara terbaik untuk meningkatkan ketahanan? adalah pertanyaan yang saya ajukan tentang masalah serupa.

Halaman malu GSLB memang memunculkan beberapa poin penting, itulah sebabnya, secara pribadi saya tidak pernah rela memilih GSLB untuk melakukan pekerjaan routing BGP.

Anda juga harus melihat titik kegagalan lain di jaringan Anda. Pastikan semua server memiliki 2 NIC (terhubung ke 2 sakelar terpisah), 2 PSU, dan bahwa layanan Anda terdiri dari beberapa server backend, sebagai pasangan berlebih, atau gugus beban-seimbang.

Pada dasarnya, DNS "load balancing" melalui beberapa catatan A hanya "berbagi-pakai" karena server DNS tidak memiliki konsep berapa banyak beban pada setiap server. Ini murah (gratis).

Layanan GSLB memiliki beberapa konsep tentang bagaimana memuat server, dan ketersediaannya, dan menyediakan beberapa resistensi yang lebih besar terhadap kegagalan, tetapi masih terganggu oleh masalah yang terkait dengan caching dns, dan pegging. Ini lebih murah, tetapi sedikit lebih baik.

Jaringan yang diarahkan BGP, didukung oleh infrastruktur yang solid, adalah IMHO, satu-satunya cara untuk benar-benar menjamin waktu kerja yang baik. Anda dapat menghemat uang dengan menggunakan server rute alih-alih router Cisco / Juniper / etc, tetapi pada akhirnya, Anda perlu mengelola server ini dengan sangat cermat. Ini sama sekali bukan pilihan yang murah, atau sesuatu yang harus dilakukan dengan ringan, tetapi ini adalah solusi yang sangat bermanfaat, dan membawa Anda ke internet sebagai penyedia, bukan hanya sebagai konsumen.


Terima kasih, saya ingin mengubah jawaban Anda tetapi tidak bisa karena saya baru. Ya, ya jaringan yang dirutekan BGP tampaknya merupakan jalan yang harus dilalui tetapi itu bisa sangat sulit untuk diatur dan dikelola untuk startup (baik dari segi biaya dan sumber daya tenaga manusia). Saya berharap ada solusi yang lebih murah untuk ini tetapi mungkin tidak ada.
Paras Chopra

1
Saya akan menulis ini sebagai esai di blog saya malam ini, saya pikir. Solusi termurah untuk router tepi untuk Anda, akan menjadi sepasang Dell R200 masing-masing dengan beberapa NIC ekstra, dan setumpuk RAM (4-6GB harus memadai), kemudian jalankan sesuatu seperti FreeBSD dan Quagga, atau BIRD.
Tom O'Connor

Fantastis! Saya pasti akan memeriksanya. Harap perbarui utas ini dengan tautan sehingga saya tidak ketinggalan.
Paras Chopra

+1 pada solusi router El-Cheapo - Kami sebenarnya menjalankan router FreeBSD di perusahaan saya dengan hasil yang bagus. Jika Anda menginginkan sesuatu yang sedikit lebih komersial (tapi masih jauh lebih murah daripada perlengkapan Cisco yang sebanding) Juniper Networks gear (www.juniper.net) juga bisa menjadi pilihan yang baik.
voretaq7

4

OK, ini ditanya beberapa waktu yang lalu, tapi saya pertama kali melihatnya sekarang.

cuplikan kode adalah JavaScript eksternal (di bagian atas kode situs), sebelum menampilkan situs web pelanggan, browser pengunjung menghubungi server aplikasi kami.

Anda harus:

  1. Tempatkan file Javascript Anda di Jaringan Pengiriman Konten yang baik dan profesional, yaitu membeli layanan Javascript HTTP (S) yang sangat tersedia dari seseorang yang sudah memiliki keahlian itu.
  2. Programlah Javascript Anda sehingga ada kondisi mundur yang baik, yaitu jika server aplikasi Anda tidak merespons dengan cepat, maka pengguna akhir akan melihat halaman normal dan tidak dimodifikasi.

Melakukan hal lain itu tidak bertanggung jawab, sungguh. Saya menganggap Anda sudah memiliki ini.

Anda tidak boleh mendasarkan layanan Anda pada trik perutean BGP kecuali Anda memiliki atau memperoleh cara melakukannya. Skenario perutean BGP yang rumit jelas tidak mudah untuk diterapkan; jangan lakukan ini sendiri jika Anda tidak memiliki pengetahuan khusus tentang domain.

Pertanyaan Anda sendiri agak membingungkan. Analisis cara membuat layanan yang sangat tersedia dimulai dengan data aplikasi , karena itulah "keadaan" Anda. Bagian-bagian tanpa kewarganegaraan mudah untuk dibuat sangat tersedia, bagian-bagian negara penuh tidak. Jadi, alih-alih berfokus pada server dan DNS Anda, lihat di mana aplikasi Anda mempertahankan status . Mulailah dengan mengoptimalkan di sana, dan mungkin meminta saran algoritma tentang Stack Overflow. Bisakah Anda menerapkan gagasan transaksi dan coba lagi server pintar di file Javascript Anda?


1

Sebenarnya, apa yang Anda inginkan dapat ditingkatkan untuk membantu aktivitas pengujian terpisah Anda juga jika Anda menggabungkan geodns dan failover dns.

Mengirim grup A ke ip 1 dan grup B ke ip 2, bahkan jika mereka berada di server yang sama akan memungkinkan Anda memisahkan grup pengujian Anda. Grup A dan Grup B berasal dari berbagai wilayah geografis. Agar adil, pada hari / minggu / bulan berikutnya, Anda membalik grup untuk memastikan bahwa Anda mengizinkan perbedaan geografis. Hanya untuk menjadi keras dalam metodologi Anda.

Layanan geodns / failover dns di http://edgedirector.com dapat melakukan ini

pengungkapan: saya terkait dengan tautan di atas, tersandung di sini meneliti sebuah artikel tentang penerapan trik dns bodoh untuk membagi pengujian.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.