Ketersediaan database adalah salah satu aspek terpenting dari arsitektur aplikasi. Sementara mencegah downtime pusat data diberikan, itu akan terjadi pada semua orang pada akhirnya. Bahkan pusat data terbaik yang dijalankan akan turun sepenuhnya setiap saat. Misalnya, Amazon AWS padam pada 26/8/13 dan 13/9/13. Pertanyaan penting untuk ditanyakan adalah apakah ini dapat diterima untuk aplikasi Anda? Sebagian besar aplikasi dapat mentolerir beberapa downtime sesekali, namun, aplikasi tertentu memerlukan hampir 100% uptime dan arsitektur database aplikasi ini memerlukan pendekatan desain yang lebih hati-hati. Latensi antara pusat data cenderung cukup besar, jadi desain penyebaran hosting MongoDB Anda harus dipikirkan dengan matang.
Tujuan Waktu Aktif MongoDB
- Basis data Anda harus aktif dan dapat ditulis, meskipun pusat data lengkap tidak berfungsi.
- Kegagalan database Anda harus otomatis jika terjadi kegagalan server/pusat data.
- Kegagalan server tunggal seharusnya tidak menyebabkan server utama beralih ke pusat data yang berbeda.
Desain Pusat Data
Untuk memenuhi tujuan kami, kami membuat tiga desain pusat data menggunakan set replika 4+1:
- Pusat Data 1: Utama (Prioritas 10), Sekunder 0 (Utama 9)
- Pusat Data 2: Sekunder 1 (Prioritas 8), Sekunder 2 (Prioritas 7)
- Pusat Data 3 Wasit
Kami menempatkan dua anggota penuh di masing-masing dari dua pusat data pertama dan seorang arbiter di pusat data ketiga. Kami juga mengonfigurasi prioritas untuk setiap server sehingga kami dapat mengontrol anggota mana yang menjadi yang utama jika terjadi kegagalan server.
Ada beberapa kelemahan dari geo- arsitektur terdistribusi:
- Jika Anda memiliki aplikasi yang banyak menulis, sekunder di pusat data yang berbeda akan selalu tertinggal karena latensi yang lebih besar. Jika beberapa data sangat penting, Anda mungkin ingin menggunakan masalah penulisan MongoDB "Mayority" untuk memastikan bahwa semua node melakukan commit data.
- Bangunan komunitas MongoDB tidak mengaktifkan SSL. Anda mungkin ingin membuat build dengan SSL yang diaktifkan atau menggunakan DBaaS MongoDB di ScaleGrid sehingga data yang mengalir di seluruh wilayah dienkripsi.
Ketersediaan Amazon AWS / EC2
Jika Anda menerapkan MongoDB di AWS, setiap pusat data dalam gambar ini sesuai dengan wilayah Amazon dan bukan dengan zona ketersediaan. Amazon tidak memberikan jaminan ketersediaan di satu zona ketersediaan, SLA untuk seluruh wilayah. Jika Anda menerapkan di seluruh zona ketersediaan, SLA Anda adalah 99,95% yang masih merupakan SLA yang bagus – namun, jika seluruh wilayah turun, database Anda akan turun. Selain itu, wilayah AWS tertentu hanya memiliki dua zona ketersediaan, sehingga perhatian khusus harus diberikan untuk menempatkan node ketiga di wilayah yang berbeda sehingga waktu henti satu wilayah tidak membuat seluruh database down.
Menurunkan Ketersediaan Biaya di Seluruh Geografis
Versi yang lebih sederhana dari arsitektur yang sama hanya menggunakan tiga server dan hanya menempatkan satu replika di setiap pusat data. Kelemahan dari pendekatan ini adalah bahwa kegagalan server tunggal akan menyebabkan server utama berpindah ke pusat data. Namun, arsitektur ini lebih murah daripada arsitektur pertama. Bergantung pada skenario Anda, ini mungkin berhasil untuk Anda.
Ada banyak cara untuk mencapai waktu kerja yang tinggi dengan MongoDB, dan ini hanya cara yang sesuai untuk kebutuhan kita. Jika Anda memiliki arsitektur menarik lainnya, silakan kirim email kepada kami di [email protected]. Kami akan senang mendengar pendapat Anda!
