Saat ini kami memiliki aplikasi n-tier klasik: DB / layanan web / front-end. Ini memiliki komponen lain, tetapi tata letak dasar.

Kami ingin meningkatkan ketersediaan aplikasi karena 3 alasan utama:

1. Tuan rumah kami terkadang mengalami pemadaman (seperti halnya mereka semua), dan kami ingin meminimalkan dampak pada pelanggan kami, jadi misalnya, mereka akan mengaktifkan pusat data B jika pusat data turun.
2. Ketika kami memutakhirkan versi, kami menutup situs untuk pemeliharaan, dan biasanya membutuhkan beberapa jam (skrip migrasi, dll). Kami ingin para pengguna memiliki transisi yang lebih mulus, dengan waktu henti seminimal mungkin (mereka menggunakan server B saat server A sedang ditingkatkan).
3. Optionnaly, pelanggan kami berlokasi di seluruh dunia, dan kami ingin mereka memiliki pengalaman terbaik yang mungkin meskipun koneksi mereka mungkin jelek (siapa pun yang bekerja dengan devs India harus tahu apa yang saya maksud). Idealnya, kami ingin dapat menghubungkan server di kantor mereka (atau menggunakan pusat data di dekat kota mereka), dan itu akan diintegrasikan dengan mulus ke dalam arsitektur kami.

Kami tidak membutuhkan ketersediaan 99%, bahkan 95%. Ini adalah aplikasi manajemen dokumen. Tidak ada yang peduli. Tetapi karena migrasi dapat berlangsung agak lama, dan ada pelanggan di seluruh dunia, kadang-kadang kami mencegah pelanggan untuk bekerja di sebagian besar hari mereka.

Untuk bagian SQL, meskipun tidak ada DBA yang "tepat", kita tahu tentang kemungkinan SQL : replikasi, mirroring, dll. Di sisi DB, cukup mudah untuk menemukan sumber daya untuk ini. Apa yang lebih sulit adalah segalanya: menyimpan sesi, kode, dll. Jika server layanan web saya turun, bagaimana UI saya tahu itu harus beralih? Bagaimana sesi saya bertahan di server?

Sayangnya, tidak ada dari kita yang memiliki pengalaman di bidang ini, dan kita bahkan tidak tahu harus mulai dari mana. Apakah ada praktik terbaik untuk ini? Pola desain? Perpustakaan (yang seharusnya gratis karena kita tidak punya uang)?

Kami menggunakan ASP.Net dan SQL Server, dengan layanan web WCF di tengah. Kami memiliki banyak layanan Windows, tetapi mereka tidak kritis terhadap misi, dan saya berasumsi metode untuk berurusan dengan situs web akan berlaku untuk layanan tersebut.

Saya mengerti bahwa sebagian besar platform cloud menyediakan sistem bawaan untuk ini, tetapi cloud hosting tidak dapat digunakan karena sysadmin kami, yang ingin mengelola semuanya sendiri dan tidak bergantung pada siapa pun.

Anda perlu mengklarifikasi ketersediaan tinggi seperti apa yang Anda cari. Ada aplikasi yang sangat tersedia yang saya jalankan yang perlu hingga 95% dari waktu. Ada yang lain yang perlu dijalankan pada 99%. Saya bisa memikirkan skenario hidup atau mati yang membutuhkan 100% uptime. Hanya mereka bertiga memiliki pendekatan dan biaya yang berbeda secara drastis.

Hanya menebak berdasarkan kebutuhan Anda dan SLA waktu aktif 95-99%:

• Migrasi basis data harus dapat terjadi secara real time untuk sebagian besar perubahan. Berlatih desain basis data Evolusi . Untuk perubahan yang memang memerlukan perilaku lebih invasif, Anda memiliki beberapa opsi. Salah satunya adalah mengambil downtime. Jika memungkinkan, menjalankan layanan Anda dalam mode baca-saja mungkin berhasil. Untuk fungsionalitas penuh, saya sudah lama ingin mencoba ScaleArc. Sepertinya alat yang sangat apik untuk penskalaan dan ketahanan di dunia SQL Server.
• Menempatkan server di dalam situs pelanggan Anda adalah resep untuk bencana yang tidak dapat dikelola kecuali Anda memiliki strategi penyebaran kelas dunia (yang, berdasarkan deskripsi migrasi Anda, Anda belum memilikinya). Jangan mendorong layanan cloud di tempat karena Anda memiliki masalah kinerja. Selesaikan masalah kinerja sekarang dan kemudian Anda tidak perlu berurusan dengan masalah yang lebih mahal.
• Server negara Anda harus berupa semacam database. Ikuti panduan HA mereka. Anda dapat menggunakan SQL Server untuk ini, karena Anda sudah memilikinya tersedia untuk Anda.
• Berbicara tentang database, replikasi tidak memungkinkan HA. Bahkan, Replikasi SQL akan menyebabkan Anda sakit kepala di setiap belokan (berbicara dari pengalaman dengan beberapa skenario replikasi node). Mirroring dapat bekerja, tetapi yang terakhir saya ingat, SQL clustering membutuhkan waktu 1-5 menit untuk gagal ke server baru. Saya sudah mendengar hal-hal baik tentang AlwaysOn, tapi saya masih curiga diberi track record Microsoft. Sesuatu seperti ScaleArc mungkin lebih membantu di sini.
• Server web Anda harus stateless. Putar tiga atau empat dan letakkan di belakang load balancer. Itu memecahkan kekhawatiran waktu kerja Anda di sana. Seperti yang disebutkan Frederik sebelumnya, Anda juga dapat melakukan penggelaran dengan cara ini.
• Layanan web Anda mungkin harus bernegara. Jika tidak, lihat apakah Anda dapat memecahnya menjadi bit stateless dan stateful. Menempatkan banyak contoh di belakang penyeimbang muatan yang sama lagi memecahkan kekhawatiran waktu kerja dan memungkinkan skenario penempatan yang lebih menarik (mis. Penyebaran biru / hijau).

Tidak seperti Frederik, saya tidak akan menyebut paranoia cloud Anda tidak beralasan. Itu tergantung pada persyaratan uptime Anda. Dapat dibayangkan bahwa suatu layanan harus berjalan di beberapa pusat data yang dioperasikan oleh penyedia yang berbeda di berbagai negara demi redundansi. Mengingat keadaan Anda saat ini, saya setuju bahwa AWS, Azure, atau yang serupa mungkin merupakan taruhan yang aman untuk perusahaan Anda.

Mendapatkan beberapa tingkat HA di tingkat web & aplikasi Anda:

1. Idealnya, faktorkan keadaan apa pun, termasuk status sesi ke sistem status bersama seperti database atau server status sesi dalam memori. Bergantung pada desain aplikasi Anda, ini dapat menyebabkan masalah kinerja karena latensi tambahan yang mendapatkan status besar.

2. Situs web & tingkat aplikasi Anda masing-masing harus memiliki penyeimbang beban independen di depannya. NGINX akan melakukan triknya, tetapi IIS dapat melakukan ini juga (ARR).

3. Jika satu basis data tidak dapat menangani pemuatan, leverage partisi status sesi (atau sharding atau hashing yang konsisten) untuk merutekan permintaan tertentu ke kotak basis data tertentu.

Jika memfaktorkan keadaan terlalu sulit, Anda dapat menggunakan afinitas server untuk penyeimbangan beban (yaitu pengguna secara konsisten dialihkan ke kotak yang sama, seringkali berbasis cookie). Ini tidak sangat tersedia sebagai pendekatan round robin stateless, karena pemadaman kotak akan berdampak pada semua pengguna & menyatakan pada kotak itu, tetapi mengalahkan pemadaman total (tergantung kasus penggunaan).

Di sisi peningkatan:

1. Rancang skrip basis data Anda sedemikian rupa sehingga pemutakhiran basis data dapat dilakukan saat sistem berjalan, dengan kata lain, mempertahankan kompatibilitas ke belakang. Pola yang bekerja dengan baik untuk itu adalah "memperluas, lalu kontrak" -> hanya membuat aditif, perubahan yang kompatibel mundur tetapi menghapus dependensi pada bidang (dll) yang ingin Anda singkirkan; kemudian tingkatkan semua klien dari basis data ke v-latest; kemudian lakukan db-upgrade lain untuk menyingkirkan bidang lama (dll) dalam database. Ini bisa menjadi proses yang lambat jika Anda memiliki basis data yang besar dan Anda harus berhati-hati untuk tidak merusak kinerja sistem Anda.

2. Meningkatkan tier aplikasi Anda: karena Anda tidak menggunakan lingkungan cloud, saya sarankan Anda mengikuti pola penyebaran kenari: lakukan pemutakhiran bergulir kotak web & tier menengah Anda. Jika penyebaran salah, keluarkan kotak dari load balancer, sama seperti Anda akan gagal.

Kata peringatan: mengembangkan sistem yang belum dirancang untuk HA menjadi sistem yang dapat menjadi proses yang panjang dan mahal. Anda harus melakukan trade-off di sepanjang jalan (biaya vs upaya untuk mencapai tingkat ketersediaan tertentu)

Cloud paranoia Anda tidak beralasan - penyedia seperti AWS bersama dengan praktik yang baik di pihak Anda dapat mengontrol / mengurangi sebagian besar risiko - lihat laman kepatuhan mereka untuk mengetahui peraturan apa yang mereka patuhi: https: // aws .amazon.com / compliance /

TL; DR: Bangun berlebihan, modular; uji ketersediaan; memonitor dengan cermat.

Setelah menyadari bahwa mencoba memeras penjelasan apa pun mungkin sangat lama sehingga saya akan menuliskan semua pengamatan yang telah saya buat.

Mempertanyakan premis

Sistem cloud adalah obat mujarab

Bahkan jika Anda ingin sepenuhnya menggunakan cloud, dengan penyedia cloud top, Anda masih perlu merancang aplikasi Anda untuk ketahanan, alasan. AWS mungkin menggantikan VM Anda, tetapi aplikasi Anda harus mampu me-restart jika dibiarkan di tengah perhitungan.

Kami tidak ingin menggunakan sistem cloud, karena x / y / z

Kecuali jika Anda adalah organisasi yang sangat besar, Anda lebih baik menggunakan sistem cloud. Sistem cloud Top-3 (AWS, MSFT, Google), mempekerjakan ribuan insinyur untuk memberi Anda SLA yang dijanjikan dan dashboard yang mudah dikelola. Ini sebenarnya tawaran yang bagus untuk menggunakannya sebagai pengganti menghabiskan uang receh di rumah ini.

Masalah dalam pelingkupan dan desain

Menentukan, mengukur, dan kemudian secara terus-menerus mengukur ketersediaan layanan merupakan tantangan yang lebih besar daripada menulis solusi untuk masalah ketersediaan.

Menentukan dan mengukur 'ketersediaan' lebih sulit dari yang diharapkan

Banyak pemangku kepentingan memiliki pandangan yang berbeda tentang ketersediaan, dan apa yang mungkin terjadi adalah definisi yang disukai oleh seseorang dengan gaji tertinggi, definisi lain. Ini kadang-kadang definisi yang benar, tetapi seringkali eko-sistem tidak dibangun untuk mengukur hal yang sama karena definisi ideal itu sangat sulit untuk diukur, apalagi memantau secara real time. Jika Anda memiliki definisi ketersediaan yang tidak dapat dipantau secara real time, Anda akan menemukan proyek serupa yang dilakukan sendiri berulang-ulang dengan kesamaan yang menakutkan. Tetap dengan sesuatu yang masuk akal dan sesuatu yang dapat dengan mudah dipantau.

Orang-orang meremehkan kompleksitas sistem yang selalu tersedia.

Untuk mengatasi gajah di dalam ruangan, izinkan saya mengatakan ini: "Tidak ada sistem multi-komputer 100% tersedia, mungkin di masa depan tetapi tidak dengan teknologi saat ini." Di sini dengan teknologi saat ini, saya mengacu pada ketidakmampuan kami mengirim sinyal lebih cepat daripada kecepatan cahaya dan hal-hal semacam itu. Semua insinyur komputer layak mengetahui keterbatasan komputasi terdistribusi , dan sebagian besar dari mereka tidak akan menyebutkannya dalam rapat, karena khawatir mereka akan terlihat seperti noobs. Untuk menebus semua yang tidak menyebutkan keterbatasan komputasi terdistribusi, saya akan mengatakan, ini rumit tetapi tidak selalu mempercayai komputer .

Orang melebih-lebihkan kemampuan insinyur mereka

Sayangnya, ketersediaan masuk dalam kategori, di mana Anda tidak tahu apa yang Anda inginkan tetapi Anda tahu apa yang tidak Anda inginkan. Agak sulit bahwa kategori 'tahu keinginan' seperti UI. Dibutuhkan sedikit pengalaman dan banyak membaca untuk belajar dari pengalaman orang lain dan lebih banyak lagi.

Membangun sistem yang tersedia dari dasar

Pastikan Anda akan menginjili kepada setiap arsitektur dan tim desain tentang prioritas ketersediaan yang tepat sebagai persyaratan sistem.

Atribut sistem membantu ketersediaan

Karakteristik sistem berikut telah terbukti berkontribusi terhadap ketersediaan sistem:

Redundansi

Beberapa contohnya adalah tidak pernah hanya memiliki satu VM di belakang VIP atau tidak pernah hanya menyimpan satu salinan data Anda. Ini adalah pertanyaan yang IAAS yang baik akan membuat Anda lebih mudah untuk menyelesaikannya tetapi Anda masih harus membuat keputusan ini.

Modularitas

REST modular lebih baik daripada SOA monolitik. Bahkan layanan modular mikro sebenarnya lebih tersedia daripada HATEOS REST yang biasa . Alasannya dapat ditemukan dalam diskusi terkait Yield di bagian selanjutnya. Jika Anda melakukan pemrosesan batch maka lebih baik untuk pemrosesan batch dalam batch 10-an yang masuk akal dibandingkan dengan berurusan dengan batch 1.000.000.

Kegembiraan

"I am always angry"
                    - Hulk

Sistem yang tangguh selalu siap untuk pulih. Ketahanan ini berlaku untuk instance seperti mengakui ACK untuk penulisan hanya setelah menulis ke disk RAID, dan mungkin pada setidaknya dua pusat data. Tren terbaru lainnya adalah menggunakan struktur data bebas konflik , di mana struktur data memikul tanggung jawab untuk menyelesaikan konflik ketika disajikan dengan dua versi yang berbeda. Suatu sistem tidak dapat bertahan sebagai renungan, itu harus diprediksi dan dibangun. Kegagalan dijamin dalam jangka panjang, jadi kita harus selalu siap dengan rencana untuk pulih.

Jejak log

Secara teknis ini adalah subtipe Ketahanan, tetapi yang sangat istimewa karena menangkap semua kemampuan. Meskipun upaya terbaik, kami mungkin tidak dapat memprediksi pola ketidaktersediaan. Jika memungkinkan, pertahankan jejak log yang cukup dari aktivitas sistem untuk dapat memutar ulang kejadian sistem. Ini akan, dengan biaya manual yang besar, memungkinkan Anda untuk pulih dari situasi yang tidak terduga.

Atribut ketersediaan

Daftar atribut top-of-mind 'ketersediaan' yang tidak lengkap: Demi diskusi, mari kita asumsikan pertanyaan yang diajukan pengguna adalah, "Berapa banyak item yang saya miliki di keranjang belanja saya?"

Ketepatan

Apakah Anda harus menghasilkan jawaban yang paling akurat atau apakah membuat kesalahan? Hanya untuk referensi, ketika Anda menarik uang dari ATM, itu tidak dijamin benar. Jika bank menemukan kesalahan, Anda mungkin membalik transaksi. Jika sistem Anda menghasilkan bilangan prima, maka saya kira, Anda mungkin ingin jawaban yang benar setiap saat.

Menghasilkan

Lewati poin ini, jika Anda selalu menjawab benar untuk pertanyaan topik sebelumnya. Terkadang jawaban atas pertanyaan tidak harus tepat, misalnya berapa banyak teman yang saya miliki di Facebook saat ini? Namun jawabannya diharapkan berada di stadion baseball +/- 1 sepanjang waktu. Ketika Anda menghasilkan hasil yang diharapkan, hasil Anda adalah 100.

Konsistensi

Jawaban Anda mungkin benar pada satu titik waktu, tetapi pada saat cahaya telah meninggalkan layar dan memasuki retina pengamat, segala sesuatu dapat berubah. Apakah itu membuat jawaban Anda salah? Tidak, itu hanya membuatnya tidak konsisten. Sebagian besar aplikasi pada akhirnya konsisten, tetapi triknya adalah menentukan model konsistensi seperti apa yang akan disediakan oleh aplikasi Anda. Secara kebetulan aplikasi Anda dapat berjalan di satu komputer, Anda dapat melewati pembacaan indah ini pada teorema CAP .

Biaya

Banyak tergantung pada apa dampak total dari efek jangka pendek (kehilangan pendapatan) dan efek jangka panjang (reputasi buruk, retensi pelanggan). Bergantung pada jenis pelanggan (pembayaran / gratis, ulangi / unik, captive) dan ketersediaan sumber daya berbagai tingkat ketersediaan jaminan harus dibangun di dalamnya.

Menuju peningkatan ketersediaan sistem yang ada

Manajemen operasional mesin individual dan jaringan sangat rumit, sehingga saya anggap Anda telah menyerahkannya kepada penyedia cloud atau Anda sudah cukup ahli untuk mengetahui apa yang Anda lakukan. Saya akan menyentuh topik lain di bawah ketersediaan. Untuk strategi jangka panjang Define-Measure-Analyze-Control adalah pertandingan surgawi, sesuatu yang telah saya lihat sendiri.

1. Tetapkan apa yang 'ketersediaan' bagi para pemangku kepentingan Anda
2. Bagaimana Anda mengukur apa yang telah Anda tetapkan
3. Analisis akar penyebab untuk mengidentifikasi kemacetan
4. Tugas untuk perbaikan
5. Pemantauan terus menerus ( kontrol ) sistem

Penyebab tidak tersedianya

Karena kami sepakat bahwa manajemen operasional yang akan mencakup manajemen infrastruktur fisik apa pun, harus dilakukan oleh para profesional, saya akan menyentuh penyebab lain ketidaktersediaan demi kelengkapan. Ketersediaan IMO juga harus mencakup kurangnya perilaku yang diharapkan, artinya jika pengguna tidak menunjukkan pengalaman yang diharapkan, maka ada sesuatu yang tidak tersedia. Dengan definisi luas tersebut, hal-hal berikut dapat menyebabkan tidak tersedianya: - Kode bug - Insiden keamanan - Masalah kinerja