Merencanakan bencana

18

Saya bekerja untuk perusahaan pemasaran kecil yang juga melakukan desain dan pengembangan web. Kami menampung semua pelanggan desain dan pengembangan web kami di server khusus di Hostgator. Kami memiliki server khusus dengan hard drive yang dikonfigurasi RAID 1. Kami juga melakukan backup mingguan yang diotomatisasi melalui cPanel dan diunduh oleh perangkat lunak FTP otomatis secara lokal.

Hari ini kami sedang mendiskusikan apa yang akan kami lakukan jika Hostgator memiliki semacam kegagalan bencana. Bisa jadi server meledak, Hostgator memiliki masalah jaringan yang serius, FBI melakukan salah satu dari razia mereka "mengambil setiap server yang kita lihat", dll. Pada dasarnya setiap skenario di mana pemadaman yang berkepanjangan diharapkan terjadi. Kami kemudian membawanya ke tingkat berikutnya dan bertanya-tanya apa yang akan kami lakukan jika Hostgator mengalami pemadaman yang berkepanjangan dan kami tidak dapat mengakses cadangan lokal kami. Ini bisa jadi karena kebakaran, banjir, dll. Saya tahu kemungkinan server kami turun untuk waktu yang lama dan file lokal kami secara bersamaan tidak dapat diakses adalah jarak jauh tetapi yang diperlukan hanya duahal-hal buruk terjadi dan di situlah kita akan berdiri. (Jika Anda pernah mendapatkan ban kempes dan mendapati bahwa ban cadangan Anda kempes atau hilang, Anda tahu betapa mudahnya dua hal buruk terjadi secara simultan).

Tidak perlu dikatakan bahwa kita ingin bersiap-siap untuk jenis peristiwa "skenario terburuk" karena ini hampir pasti akan membuat kita keluar dari bisnis. Jadi dua pertanyaan saya adalah:

  1. Apa yang bisa kita lakukan agar siap menghadapi pemadaman yang diperpanjang oleh Hostgator? Skenario yang ideal akan membuat situs web klien kami, dan mudah-mudahan email, berjalan kembali dengan cepat.

  2. Apa yang akan dicadangkan oleh rencana cadangan yang kuat sehingga data penting tidak pernah hilang? Solusi ideal akan otomatis.

Anda dapat berasumsi bahwa biaya bukanlah masalah dalam jawaban Anda tetapi solusi yang lebih terjangkau adalah, semakin baik.

John Conde
sumber
Sepertinya jawaban di sini sudah mencakup banyak alasan. Saya dapat menjamin bahwa cloud Amazon sudah sangat ekonomis sebagai solusi cadangan untuk saat ini. Tidak tahu apa yang akan terjadi di masa depan, tetapi jika tidak ada yang lain, ini adalah cara yang baik untuk mempelajari cara kerja cloud.
JMC
Berikut perkiraan kalkulator biaya untuk AWS jika Anda belum menemukannya: calculator.s3.amazonaws.com/calc5.html
JMC
@John Conde: apa pengalaman Anda dengan HostGator, apakah ada downtime utama? Jika ya, berapa lama waktu henti utama yang Anda ingat?
Marco Demaio
@Marco Demaio, kami sama sekali tidak downtime dengan Hostgator. Mereka sangat andal dan dukungan mereka fantastis.
John Conde

Jawaban:

15

Saya sarankan Anda:

  1. Secara otomatis mencerminkan seluruh konten dan konfigurasi server utama Anda ke server cadangan sekunder di jaringan yang benar-benar terpisah di pusat data yang berbeda. Gunakan RSync, FXP, cPanel voodoo, atau metode apa pun yang Anda inginkan untuk mengotomatiskan sinkronisasi.

  2. Gunakan peralihan failover DNS untuk secara otomatis merutekan lalu lintas ke server cadangan jika server Hostgator terbukti tidak responsif.

Ini berarti bahwa Anda selalu memiliki cadangan 'panas' yang menunggu untuk pergi jika terjadi yang terburuk, daripada cadangan 'dingin' yang memerlukan intervensi manual dan banyak yang berebut dan panik. Ini juga berarti bahwa klien Anda tidak akan pernah tahu bahwa situs mereka turun sebelum Anda melakukannya, yang dapat menyusahkan bagi semua orang.

Anda dapat mengatur DNS failover menggunakan penyedia seperti DNS Made Easy . Untuk setiap domain yang Anda hosting, Anda dapat mengatur hingga lima alamat IP cadangan, satu untuk masing-masing server cadangan Anda. Setelah selesai ...

  1. DNS Made Easy memeriksa server utama Anda selama dua hingga empat menit dan, jika tidak mendeteksi respons, ia merutekan lalu lintas ke alamat IP sekunder.

  2. DNS Made Easy terus memeriksa server utama. Ketika muncul, itu akan mengubah rute lalu lintas ke server pertama, atau — jika Anda suka — menyimpannya di cadangan saat Anda mendiagnosis apa yang salah dan memperbaiki server utama.

Tentu saja, solusi ini akan menaikkan biaya operasi Anda, yang bagaimanapun juga harus Anda sampaikan kepada klien, tetapi — jika Anda berada dalam industri di mana downtime akan membuat Anda gulung tikar — membayar untuk server yang sebagian besar berlebihan mungkin bernilai untuk itu sekali menyelamatkan perusahaan.

Lebih dari itu:

Gandakan, duplikat, duplikat

Semakin banyak cadangan independen yang Anda miliki, semakin baik. Saya menyimpan cadangan jarak jauh pada hard drive lokal, yang dicerminkan ke hard drive eksternal, ke Dropbox, repositori git, dan akun FTP jarak jauh. Jangan ambil risiko. Gandakan sebanyak yang Anda bisa. Jika Anda harus memulihkan dari cadangan manual, lebih baik memiliki lima pilihan daripada satu pilihan. Paranoia diremehkan.

Berlatihlah memulihkan cadangan secara manual

Jika Anda belum pernah mencoba memulihkan dari salah satu cadangan Anda, bagaimana Anda tahu itu berfungsi? Sebaiknya lakukan latihan darurat untuk melihat apa yang akan terjadi jika prosedur otomatis Anda gagal.


UPDATE: Beberapa layanan lain yang saya temukan baru-baru ini yang layak disebutkan sehubungan dengan cadangan situs, pemulihan bencana, dan mempertahankan waktu aktif:

  • Cloudflare, yang menyediakan fitur keamanan dan caching untuk menjaga situs tetap terjaga ketika server Anda mati. (Mereka mencerminkan situs Anda dan menyajikannya dari cache yang didistribusikan secara global alih-alih dari server Anda secara langsung.)
  • Codeguard, yang menyediakan cadangan otomatis dan kembalikan kode situs web (khusus FTP).
  • Situs Cadangan Otomatis, yang menyediakan cadangan otomatis dan kembalikan kode situs web, data email, dan info MySQL melalui cadangan cPanel. Perhatikan bahwa ini dijalankan oleh Hostgator, jadi itu tidak selalu cocok jika Anda meng-host situs Anda juga, tetapi mungkin membantu orang lain.

Cloudflare khususnya sepertinya akan berguna untuk menghindari downtime dan untuk secara umum meningkatkan respons situs.

Nick
sumber
Saya tidak tahu sesuatu seperti DNS menjadi mudah ada. Itu akan menjadi cara yang bagus untuk membuat situs dengan cepat dialihkan jika server utama turun.
John Conde
Mereka bagus untuk hosting DNS umum juga. Saya membeli domain dari pendaftar favorit saya tetapi menggunakan DNS Made Easy untuk meng-host catatan DNS. Mereka memiliki banyak server nama di seluruh dunia, jadi situs diselesaikan dengan cepat, memuat lebih cepat pertama kali, dan jangan turun saat server nama registrar Anda tersedak. Itu tidak mahal juga.
Nick
@Nick: di sini mereka mengatakan DNS failover (saya pikir layanan yang Anda gunakan dalam DNS Made Easy) tidak disarankan: serverfault.com/questions/60553/… Bagaimana menurut Anda?
Marco Demaio
@ Marsco Mereka benar untuk menunjukkan bahwa itu tidak mudah, tetapi bekerja sangat baik untuk saya untuk beberapa aplikasi web kecil yang saya kelola.
Nick
1
Omong-omong, Stack Exchange menggunakan DNS failover juga. Pusat data primer ada di New Yourk, sekunder di Oregon. meta.stackexchange.com/a/231138/238706 meta.stackexchange.com/q/207653/238706
Palec
6

Pemulihan bencana bisa menjadi tugas besar, terutama ketika berhadapan dengan banyak server, situs, dan basis data. Dua item utama yang harus dipertimbangkan dengan solusi yang Anda pilih adalah tujuan waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO).

RTO pada dasarnya adalah harapan berapa lama waktu yang dibutuhkan sampai situs kembali. Jika Anda memiliki RTO satu atau dua menit (atau kurang), maka Anda harus mempertimbangkan solusi yang sesuai dengan apa yang disarankan Nick yang melibatkan replikasi file dan data Anda secara real-time ke pusat data sekunder dan kegagalan otomatis DNS yang bisa dilakukan dengan layanan berbayar atau dengan perangkat keras di kedua pusat data (seperti BIG-IP Global Traffic Managerdari F5 Networks. Ini bisa menjadi mahal, tetapi sebagian besar tergantung pada menjawab pertanyaan "Berapa biaya downtime?" Jika RTO Anda beberapa jam atau bahkan beberapa hari, maka Anda dapat mempertimbangkan prosedur pemulihan bencana yang mungkin melibatkan lebih banyak keterlibatan manual seperti membawa server online, mengganti DNS, dll. Membosankan, tetapi tentu hemat biaya jika RTO Anda mengizinkannya.

RPO pada dasarnya adalah seberapa sering pencadangan dilakukan dan berapa banyak data yang ingin Anda hilangkan jika terjadi bencana. Jika perubahan pada konten dan / atau data sering terjadi, maka Anda mungkin memiliki RPO mungkin beberapa menit atau jam dan mungkin berurusan dengan replikasi waktu nyata atau cadangan frekuensi tinggi. Jika konten tidak sering berubah atau Anda memiliki pelanggan yang tidak peduli mereka kehilangan data selama beberapa hari, cadangan Anda dapat lebih jarang terjadi.

Seperti yang saya sebutkan, saya setuju dengan apa yang dikatakan oleh Nick. Alternatif lain yang mungkin ingin Anda pertimbangkan adalah memanfaatkan layanan berbasis cloud dari salah satu penyedia berbasis cloud yang lebih besar seperti Rackspace atau Amazon. Kedua penyedia tersebut secara khusus memiliki infrastruktur besar untuk dapat menangani hampir semua bencana yang terjadi pada mereka. Dengan sesuatu seperti situs cloud atau server cloud (istilah yang digunakan oleh Rackspace), Anda memiliki keuntungan dapat meningkatkan skala juga dan tidak perlu khawatir tentang aspek perangkat keras fisiknya.

Rackspace juga memiliki opsi khusus yang tersedia di mana Anda dapat mencampurkan infrastruktur Anda, memiliki kombinasi server cloud, server fisik, dan file cloud sebagai bagian dari solusi Anda. Pendekatan hibrid mungkin sesuatu yang perlu dipertimbangkan tergantung pada kebutuhan pelanggan Anda jika Anda tidak ingin mengambil pendekatan satu ukuran cocok untuk semua.

Jika ini membantu, ada halaman yang didedikasikan untuk pemulihan bencana di situs Rackspace juga yang dapat ditemukan di sini . (Juga sebagai catatan, saya tidak berafiliasi dengan Rackspace, tetapi telah menggunakan layanan mereka di masa lalu).

Semoga ini bisa membantu.

EDIT : Pikir ini mungkin membantu jika Anda mengevaluasi solusi cloud. Laporan Kuadran Gartner untuk Infrastruktur dan sebagai Layanan dan Web Hosting dapat memberi Anda wawasan tentang penyedia solusi lainnya.

rampok
sumber
Saya bahkan tidak pernah mempertimbangkan menggunakan cloud hosting sebagai cadangan "server". Itu akan menjadi cara yang sangat ekonomis untuk memiliki cadangan yang siap digunakan dengan cepat.
John Conde
2

Replikasi lengkap server di fasilitas lain dari perusahaan hosting lain tampaknya merupakan solusi yang paling jelas.

File dapat disimpan dalam sinkronisasi dengan alat-alat seperti rsync dan serempak. Cadangan SQL juga dapat dirubah dan kemudian diunggah ke slave db oleh skrip.

ZJR
sumber
1

Pastikan Anda menjalankan kontrol versi dari semua kode Anda dengan repositori kode sumber (SVN atau GIT). Apakah Anda menggunakan SVN atau GIT?

Anda bisa mendapatkan akun (gratis atau berbayar) di repositori pihak ketiga, seperti Project Locker , dan jika Anda versi semua kode Anda saat Anda sedang bekerja, pada dasarnya Anda memiliki semuanya didukung ke repositori Anda yang berada di lokasi ketiga . Dengan demikian semakin mengurangi peluang Anda (hampir nol) kehilangan semua pekerjaan sekaligus.

Anda dapat melakukan komit / checkout SVN melalui baris perintah, atau melalui klien seperti Versi (untuk Mac) atau TortoiseSVN (untuk Windows).

Joel Glovier
sumber
Satu-satunya masalah dengan repositori kode sumber tidak membuat cadangan database atau file yang diunggah pengguna dll
Daveo
Benar. Tetapi Anda dapat membuat file dump dari database Anda dan menambahkannya ke repositori. Anda bahkan dapat menulis skrip untuk menjadikannya proses otomatis. Dengan database atau tanpa, setidaknya satu tempat lagi untuk membuat kode dan aset Anda didukung, dengan manfaat utama dari kontrol versi pada semua hal itu.
Joel Glovier
Sayangnya kami tidak menggunakan kontrol versi. Bahkan, sebelum saya mulai di sini, semua pekerjaan dilakukan di situs langsung! Saya dapat mengatur lingkungan pengembangan secara lokal sehingga setidaknya praktik tersebut secara resmi mati.
John Conde