Bagaimana perasaan Anda jika suatu hari di musim panas, pusat data dengan peralatan Anda terlihat seperti ini?
Halo semua! Nama saya Dmitry Samsonov, saya bekerja sebagai administrator sistem terkemuka di "" Foto menunjukkan salah satu dari empat pusat data tempat peralatan yang melayani proyek kami dipasang. Di balik tembok ini terdapat sekitar 4 ribu peralatan: server, sistem penyimpanan data, peralatan jaringan, dll. - hampir ⅓ dari semua peralatan kami.
Sebagian besar server adalah Linux. Ada juga beberapa lusin server di Windows (MS SQL) - warisan kami, yang telah kami tinggalkan secara sistematis selama bertahun-tahun.
Jadi, pada tanggal 5 Juni 2019 pukul 14:35, teknisi di salah satu pusat data kami melaporkan adanya alarm kebakaran.
Penyangkalan
14:45. Insiden asap kecil di pusat data lebih sering terjadi daripada yang Anda kira. Indikator di dalam aula normal, jadi reaksi pertama kami relatif tenang: mereka memberlakukan larangan bekerja dengan produksi, yaitu, pada perubahan konfigurasi apa pun, meluncurkan versi baru, dll., kecuali untuk pekerjaan yang berkaitan dengan perbaikan sesuatu.
Kemarahan
Pernahkah Anda mencoba mencari tahu dari petugas pemadam kebakaran di mana tepatnya kebakaran terjadi di atap, atau pergi sendiri ke atap yang terbakar untuk menilai situasinya? Berapa tingkat kepercayaan terhadap informasi yang diterima melalui lima orang?
14: 50. Informasi yang diterima api mendekati sistem pendingin. Tapi apakah itu akan datang? Administrator sistem yang bertugas menghapus lalu lintas eksternal dari depan pusat data ini.
Saat ini, bagian depan semua layanan kami diduplikasi di tiga pusat data, penyeimbangan digunakan di tingkat DNS, yang memungkinkan kami menghapus alamat satu pusat data dari DNS, sehingga melindungi pengguna dari potensi masalah dengan akses ke layanan . Jika masalah sudah terjadi di pusat data, ia akan meninggalkan rotasi secara otomatis. Anda dapat membaca lebih lanjut di sini:
Kebakaran tersebut belum berdampak apa pun kepada kami - baik pengguna maupun peralatan tidak mengalami kerusakan. Apakah ini kecelakaan? Bagian pertama dari dokumen “Rencana Tindakan Kecelakaan” mendefinisikan konsep “Kecelakaan”, dan bagian tersebut berakhir seperti ini:
«Jika ada keraguan apakah ada kecelakaan atau tidak, maka itu adalah kecelakaan!»
14:53. Seorang koordinator darurat ditunjuk.
Koordinator adalah orang yang mengontrol komunikasi antara semua peserta, menilai skala kecelakaan, menggunakan Rencana Tindakan Darurat, menarik personel yang diperlukan, memantau penyelesaian perbaikan, dan yang terpenting, mendelegasikan tugas apa pun. Dengan kata lain, orang inilah yang mengatur seluruh proses tanggap darurat.
Tawar-menawar
15:01. Kami mulai menonaktifkan server yang tidak terkait dengan produksi.
15:03. Kami mematikan semua layanan yang dipesan dengan benar.
Ini tidak hanya mencakup front (yang saat ini tidak lagi dapat diakses pengguna) dan layanan tambahannya (logika bisnis, cache, dll.), tetapi juga berbagai database dengan faktor replikasi 2 atau lebih (, , , dll.).
15: 06. Diterima informasi bahwa kebakaran mengancam salah satu aula pusat data. Kami tidak memiliki peralatan di ruangan ini, namun fakta bahwa api dapat menyebar dari atap ke aula sangat mengubah gambaran tentang apa yang terjadi.
(Belakangan ternyata tidak ada ancaman fisik terhadap aula tersebut, karena atapnya tertutup rapat. Ancaman hanya terjadi pada sistem pendingin aula ini.)
15:07. Kami mengizinkan eksekusi perintah di server dalam mode dipercepat tanpa pemeriksaan tambahan ().
15:08. Suhu di aula berada dalam batas normal.
15: 12. Peningkatan suhu di aula tercatat.
15:13. Lebih dari separuh server di pusat data dimatikan. Ayo lanjutkan.
15:16. Keputusan dibuat untuk mematikan semua peralatan.
15:21. Kami mulai mematikan daya ke server stateless tanpa mematikan aplikasi dan sistem operasi dengan benar.
15:23. Sekelompok orang yang bertanggung jawab atas MS SQL dialokasikan (jumlahnya sedikit, ketergantungan layanan pada mereka tidak besar, tetapi prosedur untuk memulihkan fungsionalitas membutuhkan waktu lebih lama dan lebih rumit daripada, misalnya, Cassandra).
Депрессия
15: 25. Informasi diterima tentang pemadaman listrik di empat dari 16 aula (No. 6, 7, 8, 9). Peralatan kami terletak di aula 7 dan 8. Tidak ada informasi tentang dua aula kami (No. 1 dan 3).
Biasanya jika terjadi kebakaran, pasokan listrik langsung dimatikan, namun dalam kasus ini, berkat kerja terkoordinasi dari petugas pemadam kebakaran dan tenaga teknis pusat data, pasokan listrik tidak dimatikan di mana-mana dan tidak segera, melainkan sesuai kebutuhan.
(Belakangan diketahui bahwa listrik di aula 8 dan 9 tidak dimatikan.)
15:28. Kami mulai menerapkan database MS SQL dari cadangan di pusat data lain.
Itu akan makan waktu berapa lama? Apakah kapasitas jaringan cukup untuk seluruh rute?
15: 37. Penutupan beberapa bagian jaringan tercatat.
Manajemen dan jaringan produksi secara fisik terisolasi satu sama lain. Jika jaringan produksi tersedia, Anda dapat pergi ke server, menghentikan aplikasi dan mematikan OS. Jika tidak tersedia, maka Anda dapat login melalui IPMI, menghentikan aplikasi dan mematikan OS. Jika tidak ada jaringan apa pun, maka Anda tidak dapat melakukan apa pun. “Terima kasih, Cap!”, Anda akan berpikir.
“Dan secara umum, terdapat banyak kekacauan,” Anda mungkin juga berpikir.
Masalahnya adalah server, bahkan tanpa api, menghasilkan panas dalam jumlah besar. Lebih tepatnya, ketika ada pendinginan, mereka menghasilkan panas, dan ketika tidak ada pendinginan, mereka menciptakan neraka yang mengerikan, yang, paling banter, akan melelehkan sebagian peralatan dan mematikan bagian lainnya, dan paling buruk... menyebabkan a api di dalam aula, yang hampir dijamin akan menghancurkan segalanya.
15:39. Kami memperbaiki masalah dengan database conf.
Basis data conf adalah backend untuk layanan dengan nama yang sama, yang digunakan oleh semua aplikasi produksi untuk mengubah pengaturan dengan cepat. Tanpa basis ini, kita tidak dapat mengontrol pengoperasian portal, namun portal itu sendiri dapat berfungsi.
15:41. Sensor suhu pada peralatan jaringan Inti mencatat pembacaan mendekati batas maksimum yang diizinkan. Ini adalah kotak yang menempati seluruh rak dan memastikan pengoperasian semua jaringan di dalam pusat data.
15:42. Pelacak isu dan wiki tidak tersedia, alihkan ke standby.
Ini bukan produksi, namun jika terjadi kecelakaan, ketersediaan basis pengetahuan bisa menjadi sangat penting.
15:50. Salah satu sistem pemantauan telah dimatikan.
Ada beberapa dari mereka, dan mereka bertanggung jawab atas berbagai aspek layanan. Beberapa dari mereka dikonfigurasi untuk beroperasi secara mandiri dalam setiap pusat data (yaitu, mereka hanya memonitor pusat data mereka sendiri), yang lain terdiri dari komponen terdistribusi yang secara transparan bertahan dari hilangnya pusat data mana pun.
Dalam hal ini, ia berhenti bekerja , yang beroperasi dalam mode master-siaga. Beralih ke siaga.
Adopsi
15:51. Semua server kecuali MS SQL dimatikan melalui IPMI tanpa dimatikan dengan benar.
Apakah Anda siap untuk manajemen server besar-besaran melalui IPMI jika diperlukan?
Saat penyelamatan peralatan di pusat data selesai pada tahap ini. Segala sesuatu yang bisa dilakukan telah dilakukan. Beberapa rekan bisa beristirahat.
16: 13. Informasi diterima bahwa pipa freon dari AC pecah di atap - ini akan menunda peluncuran pusat data setelah api padam.
16:19. Berdasarkan data yang diterima dari staf teknis pusat data, kenaikan suhu di aula telah berhenti.
17:10. Basis data conf telah dipulihkan. Sekarang kita dapat mengubah pengaturan aplikasi.
Mengapa hal ini sangat penting jika semuanya toleran terhadap kesalahan dan berfungsi bahkan tanpa satu pusat data?
Pertama, tidak semuanya toleran terhadap kesalahan. Terdapat berbagai layanan sekunder yang belum mampu bertahan dari kegagalan pusat data dengan cukup baik, dan terdapat database dalam mode master-siaga. Kemampuan untuk mengelola pengaturan memungkinkan Anda melakukan segala sesuatu yang diperlukan untuk meminimalkan dampak akibat kecelakaan terhadap pengguna bahkan dalam kondisi sulit.
Kedua, menjadi jelas bahwa pengoperasian pusat data tidak akan pulih sepenuhnya dalam beberapa jam mendatang, sehingga perlu mengambil tindakan untuk memastikan bahwa tidak tersedianya replika dalam jangka panjang tidak menyebabkan masalah tambahan seperti disk penuh di pusat data yang tersisa.
17:29. Waktunya Pizza! Kami mempekerjakan manusia, bukan robot.
Rehabilitasi
18:02. Di aula No. 8 (milik kami), 9, 10 dan 11 suhu sudah stabil. Salah satu yang masih offline (No. 7) menampung peralatan kami, dan suhu di sana terus meningkat.
18:31. Mereka mengizinkan untuk menyalakan peralatan di aula No. 1 dan 3 - aula ini tidak terkena dampak kebakaran.
Saat ini, server sedang diluncurkan di aula No. 1, 3, 8, dimulai dari yang paling kritis. Pengoperasian yang benar dari semua layanan yang berjalan diperiksa. Masih ada permasalahan pada aula no 7.
18:44. Staf teknis pusat data menemukan bahwa di ruangan No. 7 (di mana hanya peralatan kami berada) banyak server yang tidak dimatikan. Menurut data kami, 26 server tetap online di sana. Setelah pemeriksaan kedua, kami menemukan 58 server.
20:18. Teknisi pusat data meniupkan udara melalui ruangan tanpa AC melalui saluran bergerak yang melewati lorong.
23:08. Admin pertama disuruh pulang. Seseorang perlu tidur di malam hari agar dapat melanjutkan pekerjaan besok. Selanjutnya, kami akan merilis beberapa admin dan pengembang lagi.
02:56. Kami meluncurkan segala sesuatu yang bisa diluncurkan. Kami melakukan banyak pemeriksaan terhadap semua layanan menggunakan pengujian otomatis.
03:02. AC di aula terakhir ke-7 telah dipulihkan.
03:36. Kami memutar bagian depan pusat data di DNS. Mulai saat ini lalu lintas pengguna mulai berdatangan.
Kami memulangkan sebagian besar tim administrasi. Tapi kami meninggalkan beberapa orang.
Pertanyaan Umum Kecil:
Q: Apa yang terjadi pada pukul 18:31 hingga 02:56?
J: Mengikuti “Rencana Aksi Bencana”, kami meluncurkan semua layanan, dimulai dari layanan yang paling penting. Dalam hal ini, koordinator dalam obrolan memberikan layanan kepada administrator gratis, yang memeriksa apakah OS dan aplikasi telah dimulai, apakah ada kesalahan, dan apakah indikatornya normal. Setelah peluncuran selesai, dia melaporkan ke chat bahwa dia bebas dan menerima layanan baru dari koordinator.
Proses ini semakin diperlambat oleh kegagalan perangkat keras. Meskipun menghentikan OS dan mematikan server berjalan dengan benar, beberapa server tidak kembali karena kegagalan mendadak pada disk, memori, dan sasis. Ketika listrik padam, tingkat kegagalan meningkat.
T: Mengapa Anda tidak bisa menjalankan semuanya sekaligus, lalu memperbaiki apa yang muncul dalam pemantauan?
A: Semuanya harus bertahap, karena ada ketergantungan antar layanan. Dan Anda harus segera memeriksa semuanya, tanpa menunggu pemantauan - karena lebih baik segera mengatasi masalah, tanpa menunggu masalah menjadi lebih buruk.
7:40. Admin (koordinator) terakhir pergi tidur. Pekerjaan hari pertama telah selesai.
8:09. Pengembang pertama, insinyur dan administrator pusat data (termasuk koordinator baru) memulai pekerjaan restorasi.
09:37. Kami mulai meninggikan aula No. 7 (yang terakhir).
Pada saat yang sama, kami terus memulihkan apa yang tidak diperbaiki di ruangan lain: mengganti disk/memori/server, memperbaiki segala sesuatu yang “terbakar” dalam pemantauan, mengalihkan peran kembali dalam skema master-siaga dan hal-hal kecil lainnya, yang mana ada padahal cukup banyak.
17:08. Kami mengizinkan semua pekerjaan rutin dengan produksi.
21:45. Pekerjaan hari kedua selesai.
09:45. Hari ini hari Jum'at. Masih cukup banyak permasalahan kecil dalam pemantauan. Akhir pekan sudah dekat, semua orang ingin bersantai. Kami terus melakukan perbaikan besar-besaran semampu kami. Tugas admin reguler yang bisa saja ditunda ditunda. Koordinatornya baru.
15:40. Tiba-tiba setengah dari tumpukan peralatan jaringan Inti di pusat data LAIN dimulai ulang. Bagian depan dikeluarkan dari rotasi untuk meminimalkan risiko. Tidak ada efek bagi pengguna. Belakangan ternyata sasisnya rusak. Koordinator sedang berupaya memperbaiki dua kecelakaan sekaligus.
17:17. Pengoperasian jaringan di pusat data lain telah dipulihkan, semuanya telah diperiksa. Pusat data dirotasi.
18:29. Pekerjaan hari ketiga dan secara umum restorasi pasca kecelakaan telah selesai.
penutup
04.04.2013 , "Teman Sekelas" —selama tiga hari portal tidak tersedia seluruhnya atau sebagian. Sepanjang waktu ini, lebih dari 100 orang dari berbagai kota, dari berbagai perusahaan (sekali lagi terima kasih banyak!), secara jarak jauh dan langsung di pusat data, secara manual dan otomatis, memperbaiki ribuan server.
Kami telah menarik kesimpulan. Untuk mencegah hal ini terulang kembali, kami telah melakukan dan terus melakukan pekerjaan ekstensif hingga saat ini.
Apa perbedaan utama antara kecelakaan saat ini dan 404?
- Kami memiliki “Rencana Tindakan Kecelakaan”. Seperempat sekali, kami melakukan latihan - kami memainkan peran situasi darurat, yang harus dihilangkan oleh sekelompok administrator (semuanya secara bergiliran) menggunakan “Rencana Tindakan Darurat”. Administrator sistem terkemuka bergiliran memainkan peran sebagai koordinator.
- Setiap tiga bulan, dalam mode pengujian, kami mengisolasi pusat data (secara bergantian) melalui jaringan LAN dan WAN, yang memungkinkan kami mengidentifikasi kemacetan dengan cepat.
- Lebih sedikit disk yang rusak, karena kami telah memperketat standar: lebih sedikit jam pengoperasian, ambang batas yang lebih ketat untuk SMART,
- Kami sepenuhnya meninggalkan BerkeleyDB, database lama dan tidak stabil yang memerlukan banyak waktu untuk pulih setelah server dimulai ulang.
- Kami mengurangi jumlah server dengan MS SQL dan mengurangi ketergantungan pada server lainnya.
- Kami punya milik kami sendiri , tempat kami telah aktif memigrasikan semua layanan selama dua tahun sekarang. Cloud sangat menyederhanakan seluruh siklus kerja dengan aplikasi, dan jika terjadi kecelakaan, cloud menyediakan alat unik seperti:
- penghentian yang benar dari semua aplikasi dalam satu klik;
- migrasi aplikasi yang mudah dari server yang gagal;
- peringkat otomatis (dalam urutan prioritas layanan) peluncuran seluruh pusat data.
Kecelakaan yang dijelaskan dalam artikel ini merupakan yang terbesar sejak hari ke-404. Tentu saja tidak semuanya berjalan lancar. Misalnya, ketika pusat data yang rusak akibat kebakaran tidak tersedia di pusat data lain, disk di salah satu server gagal, artinya, hanya satu dari tiga replika di cluster Cassandra yang tetap dapat diakses, itulah sebabnya 4,2% pengguna seluler pengguna aplikasi tidak bisa login. Pada saat yang sama, pengguna yang sudah terhubung terus bekerja. Secara total, lebih dari 30 masalah teridentifikasi sebagai akibat dari kecelakaan tersebut - mulai dari bug dangkal hingga kekurangan dalam arsitektur layanan.
Namun perbedaan paling penting antara kecelakaan saat ini dan kecelakaan 404 adalah saat kami menghilangkan dampak kebakaran, pengguna masih mengirim SMS dan melakukan panggilan video ke , bermain game, mendengarkan musik, saling memberi hadiah, menonton video, serial TV, dan saluran TV , dan juga mengalir masuk .
Bagaimana kelanjutan kecelakaan Anda?
Sumber: www.habr.com