Apa yang akan Anda rasakan jika, suatu hari di musim panas, pusat data dengan peralatan Anda akan terlihat seperti ini?
Halo semuanya! Nama saya Dmitry Samsonov, saya bekerja sebagai administrator sistem terkemuka di
Odnoklassniki . Foto tersebut menunjukkan salah satu dari empat pusat data di mana peralatan yang melayani proyek kami dipasang. Di balik tembok ini ada sekitar 4 ribu unit peralatan: server, sistem penyimpanan data, peralatan jaringan, dll. - hampir ⅓ dari semua peralatan kami.
Sebagian besar server adalah Linux. Ada beberapa lusinan server Windows (MS SQL) - warisan kami, yang telah kami tolak secara sistematis selama bertahun-tahun.
Jadi, pada 5 Juni 2019 pukul 14.35 para insinyur dari salah satu pusat data kami melaporkan alarm kebakaran.
Bantahan
14:45 Insiden berasap kecil di pusat data lebih umum daripada yang terlihat. Indikator di dalam aula itu normal, jadi reaksi pertama kami relatif tenang: kami memperkenalkan larangan bekerja dengan produksi, yaitu, pada setiap perubahan konfigurasi, meluncurkan versi baru, dll., Kecuali untuk pekerjaan yang terkait dengan memperbaiki sesuatu.
Amarah
Pernahkah Anda mencoba mencari tahu dari petugas pemadam kebakaran persis di mana di atap ada api, atau untuk mendapatkan diri sendiri di atap terbakar untuk menilai situasi? Apa yang akan menjadi tingkat kepercayaan pada informasi yang diterima melalui lima orang?
14:50
Informasi telah diterima bahwa api sedang mendekati sistem pendingin . Tapi apakah itu akan datang? Administrator sistem yang bertugas menampilkan lalu lintas eksternal dari bagian depan pusat data ini.
Saat ini, bagian depan semua layanan kami digandakan di tiga pusat data, penyeimbangan di tingkat DNS digunakan, yang memungkinkan Anda untuk menghapus alamat satu pusat data dari DNS, sehingga melindungi pengguna dari masalah potensial dengan akses ke layanan. Jika masalah telah terjadi di pusat data, maka secara otomatis meninggalkan rotasi. Rincian lebih lanjut dapat ditemukan di sini: Penyeimbangan muatan dan toleransi kesalahan di Odnoklassniki.
Api belum mempengaruhi kami dengan cara apa pun - baik pengguna maupun peralatan tidak terpengaruh. Apakah ini kecelakaan? Bagian pertama dari dokumen "Rencana Aksi Kecelakaan" mendefinisikan konsep "Kecelakaan", dan bagian berakhir sebagai berikut:
“ Jika ragu, kecelakaan atau tidak, maka ini kecelakaan! "14:53 Seorang koordinator kecelakaan ditunjuk.
Koordinator adalah orang yang mengendalikan komunikasi antara semua peserta, memperkirakan skala kecelakaan, menggunakan "Rencana Aksi Kecelakaan", menarik staf yang diperlukan, memantau penyelesaian perbaikan, dan yang paling penting, mendelegasikan tugas apa pun. Dengan kata lain, ini adalah orang yang mengelola seluruh proses penghapusan kecelakaan.
Tawar-menawar
15:01 Kami mulai memutuskan koneksi server yang tidak terkait dengan produksi.
15:03 Matikan semua layanan yang dipesan dengan benar.
Ini tidak hanya mencakup front (yang pada saat ini pengguna tidak lagi masuk ke) dan layanan tambahan mereka (logika bisnis, cache, dll.), Tetapi juga berbagai database dengan faktor replikasi 2 atau lebih (
Cassandra ,
penyimpanan data biner) ,
penyimpanan dingin ,
NewSQL , dll.).
15:06.
Informasi telah diterima bahwa kebakaran mengancam salah satu ruang pusat data. Kami tidak memiliki peralatan di aula ini, tetapi fakta bahwa api dapat menyebar dari atap ke aula sangat mengubah gambaran tentang apa yang terjadi.
(Belakangan ternyata tidak ada ancaman fisik terhadap aula, karena ia terisolir dari atap. Ancaman itu hanya untuk sistem pendingin aula ini.)
15:07. Kami mengizinkan eksekusi perintah pada server dalam mode dipercepat tanpa pemeriksaan tambahan (
tanpa kalkulator favorit kami ).
15:08. Suhu di kamar berada dalam batas normal.
15:12.
Peningkatan suhu di aula dicatat.15:13. Lebih dari setengah server di pusat data dimatikan. Kami melanjutkan.
15:16. Diputuskan untuk mematikan semua peralatan.
3:21 malam Kami mulai mematikan daya pada stateless-server tanpa mematikan aplikasi dan OS dengan benar.
15:23. Sekelompok orang yang bertanggung jawab untuk MS SQL dipilih (ada beberapa dari mereka, ketergantungan layanan pada mereka tidak besar, tetapi prosedur pemulihan memakan waktu lebih lama dan lebih rumit daripada, misalnya, Cassandra).
Depresi
15:25.
Informasi diterima tentang mematikan daya di empat dari 16 kamar (No. 6, 7, 8, 9). Di aula 7 dan 8 adalah peralatan kami. Tidak ada informasi lebih lanjut tentang dua kamar kami (No. 1 dan 3).
Biasanya, selama kebakaran, daya dimatikan segera, tetapi dalam kasus ini, berkat pekerjaan petugas pemadam kebakaran dan tenaga teknis pusat data yang terkoordinasi, daya dimatikan tidak di mana-mana dan tidak langsung, tetapi jika perlu.
(Belakangan ternyata kekuatan di aula 8 dan 9 tidak mati.)
15:28 Kami mulai menggunakan database MS SQL dari cadangan di pusat data lainnya.
Berapa lama? Apakah ada bandwidth jaringan yang cukup untuk seluruh rute?
15:37.
Mengunci beberapa bagian jaringan.Manajemen dan jaringan produksi secara fisik terisolasi satu sama lain. Jika jaringan produksi tersedia, maka Anda dapat pergi ke server, menghentikan aplikasi dan mematikan OS. Jika tidak tersedia, maka Anda dapat melalui IPMI, menghentikan aplikasi dan mematikan OS. Jika tidak ada jaringan, maka Anda tidak dapat melakukan apa pun. "Terima kasih, topi!" Anda akan berpikir.
"Ngomong-ngomong, ada banyak kebingungan," Anda mungkin juga berpikir.
Masalahnya adalah bahwa server bahkan tanpa api menghasilkan banyak panas. Lebih tepatnya, ketika ada pendinginan, mereka menghasilkan panas, dan ketika tidak ada, mereka menciptakan neraka neraka, yang paling baik akan melelehkan beberapa peralatan dan mematikan yang lain, dan paling buruk ... itu akan menyebabkan api di dalam aula, yang hampir pasti akan menghancurkan segalanya.
15:39. Kami memperbaiki masalah dengan database conf.
Database conf adalah backend untuk layanan dengan nama yang sama, yang digunakan oleh semua aplikasi produksi untuk dengan cepat mengubah pengaturan. Tanpa basis ini, kami tidak dapat mengontrol portal, tetapi portal itu sendiri dapat berfungsi.
15:41. Sensor suhu pada peralatan jaringan Core merekam bacaan mendekati maksimum yang diizinkan. Ini adalah kotak yang menempati seluruh rak dan memastikan pengoperasian semua jaringan di dalam pusat data.
15:42. Pelacak masalah dan wiki tidak tersedia, beralih ke siaga.
Ini bukan produksi, tetapi dalam suatu kecelakaan, ketersediaan basis pengetahuan apa pun bisa menjadi sangat penting.
15:50. Salah satu sistem pemantauan telah terputus.
Ada beberapa dari mereka, dan mereka bertanggung jawab atas berbagai aspek pekerjaan layanan. Beberapa dari mereka dikonfigurasikan untuk bekerja secara mandiri di dalam masing-masing pusat data (yaitu, mereka hanya memantau pusat data mereka), sementara yang lain terdiri dari komponen terdistribusi yang secara transparan selamat dari hilangnya pusat data apa pun.
Dalam hal ini,
sistem untuk mendeteksi anomali dalam indikator logika bisnis yang bekerja dalam mode master-standby telah berhenti berfungsi. Beralih ke standby.
Penerimaan
15:51. Melalui IPMI, semua server kecuali MS SQL dimatikan tanpa shutdown yang benar.
Apakah Anda siap untuk manajemen server massal melalui IPMI jika perlu?
Saat penyelamatan peralatan di pusat data pada tahap ini selesai. Semua yang bisa dilakukan telah dilakukan. Beberapa rekan dapat bersantai.
16:13.
Ada informasi bahwa tabung freon dari AC meledak di atap - ini akan menunda peluncuran pusat data setelah menghilangkan api.16:19. Menurut data yang diterima dari staf teknis dari pusat data, kenaikan suhu di aula berhenti.
17:10. Memulihkan pekerjaan database conf. Sekarang kita dapat mengubah pengaturan aplikasi.
Mengapa begitu penting jika semuanya toleran terhadap kesalahan dan berfungsi bahkan tanpa satu pusat data?
Pertama, tidak semua toleran terhadap kesalahan. Ada berbagai layanan sekunder yang tidak bertahan dari kegagalan pusat data dengan cukup baik, dan ada pangkalan dalam mode master-standby. Kemampuan untuk mengelola pengaturan memungkinkan Anda untuk melakukan segala yang diperlukan untuk meminimalkan dampak konsekuensi kecelakaan pada pengguna bahkan dalam kondisi sulit.
Kedua, menjadi jelas bahwa dalam beberapa jam ke depan pusat data tidak akan sepenuhnya pulih, sehingga perlu untuk mengambil langkah-langkah sehingga tidak tersedianya replika jangka panjang tidak menyebabkan masalah tambahan seperti overflow disk di pusat data yang tersisa.
17:29 Waktu pizza! Kami memiliki orang yang bekerja, bukan robot.
Rehabilitasi
18:02 Di kamar No. 8 (kita), 9, 10 dan 11, suhu stabil. Dalam salah satu dari mereka yang tetap terputus (No. 7), peralatan kami berada, dan suhu di sana terus meningkat.
18:31 Mereka memberi lampu hijau untuk meluncurkan peralatan di aula No. 1 dan 3 - api tidak memengaruhi aula ini.
Saat ini, server sedang diluncurkan di aula No. 1, 3, 8, dimulai dengan yang paling kritis. Periksa operasi yang benar dari semua layanan yang berjalan. Masih ada masalah dengan kamar 7.
18:44. Staf teknis dari pusat data menemukan bahwa di aula nomor 7 (di mana hanya peralatan kami berada), banyak server tidak dimatikan. Menurut data kami, 26 server tetap ada. Setelah memeriksa ulang, kami menemukan 58 server.
20:18 Staf teknis dari pusat data meniupkan udara di dalam ruangan tanpa AC melalui saluran seluler yang diletakkan di koridor.
23:08 Mereka membiarkan admin pertama pulang. Seseorang harus tidur di malam hari untuk melanjutkan pekerjaan besok. Selanjutnya, kami merilis bagian lain dari admin dan pengembang.
02:56. Kami meluncurkan semua yang bisa diluncurkan. Kami melakukan pemeriksaan besar semua layanan dengan autotests.
03:02 pagi Pendingin udara di aula terakhir, ke 7 dipulihkan.
03:36. Mereka membawa front di pusat data ke dalam rotasi dalam DNS. Mulai saat ini, lalu lintas pengguna mulai berdatangan.
Kami membubarkan sebagian besar tim administrator rumah. Tetapi kami meninggalkan beberapa orang.
FAQ kecil:
P: Apa yang terjadi dari 18:31 hingga 02:56?
A: Mengikuti "Rencana Aksi Kecelakaan", kami meluncurkan semua layanan, dimulai dengan yang paling penting. Pada saat yang sama, koordinator dalam obrolan memberikan layanan kepada administrator gratis, yang memeriksa apakah OS dan aplikasi telah dimulai, jika ada kesalahan, atau indikatornya normal. Setelah peluncuran selesai, ia memberi tahu obrolan bahwa ia bebas dan menerima layanan baru dari koordinator.
Proses ini juga dihambat oleh besi yang gagal. Bahkan jika OS shutdown dan shutdown server sudah benar, beberapa server tidak kembali karena tiba-tiba gagal drive, memori, atau sasis. Dengan hilangnya daya, tingkat kegagalan meningkat.
T: Mengapa Anda tidak bisa memulai semuanya sekaligus, dan kemudian memperbaiki apa yang keluar dari pemantauan?
A: Semuanya perlu dilakukan secara bertahap, karena ada ketergantungan antara layanan. Dan semuanya harus segera diperiksa, tanpa menunggu pemantauan - karena lebih baik langsung menangani masalah, bukan menunggu kejengkelannya.
7:40 pagi Admin (koordinator) terakhir pergi tidur. Pekerjaan hari pertama selesai.
8:09 pagi Pengembang pertama, insinyur di pusat data dan administrator (termasuk koordinator baru) memulai pekerjaan restorasi.
09:37. Kami mulai menaikkan aula nomor 7 (yang terakhir).
Pada saat yang sama, kami terus memulihkan apa yang tidak kami selesaikan di ruangan lain: mengganti disk / memori / server, memperbaiki segala sesuatu yang terbakar dalam pemantauan, beralih peran terbalik di sirkuit master-standby, dan hal-hal kecil lainnya, yang bagaimanapun cukup banyak.
17:08 Izinkan semua pekerjaan reguler dengan produksi.
21:45 Pekerjaan hari kedua selesai.
09:45. Hari ini hari Jumat. Masih ada beberapa masalah kecil dalam pemantauan. Menjelang akhir pekan, semua orang ingin bersantai. Kami terus memperbaiki segala sesuatu yang mungkin secara besar-besaran. Tugas admin reguler yang bisa ditunda ditunda. Koordinator itu baru.
15:40 Tiba-tiba, setengah dari tumpukan Core peralatan jaringan di pusat data OTHER dimulai kembali. Front dihapus dari rotasi untuk meminimalkan risiko. Tidak ada efek untuk pengguna. Kemudian ternyata itu adalah sasis yang buruk. Koordinator bekerja dengan memperbaiki dua crash sekaligus.
17:17 Jaringan di pusat data lain dipulihkan, semuanya diperiksa. Pusat data dalam rotasi.
18:29 Pekerjaan hari ketiga dan, secara umum, pemulihan dari kecelakaan selesai.
Kata penutup
04/04/2013,
pada hari kesalahan ke-404 , Odnoklassniki
selamat dari kecelakaan besar - selama tiga hari portal sepenuhnya atau sebagian tidak tersedia. Sepanjang waktu ini, lebih dari 100 orang dari kota yang berbeda, dari perusahaan yang berbeda (terima kasih banyak lagi!) Secara jarak jauh dan langsung di pusat data, secara manual dan otomatis memperbaiki ribuan server.
Kami telah menarik kesimpulan. Untuk mencegah hal ini terjadi lagi, kami telah melakukan dan terus melakukan pekerjaan yang luas hingga hari ini.
Apa perbedaan utama antara kecelakaan saat ini dan 404?
- Kami sudah mendapat "Rencana Tindakan Darurat". Sekali seperempat, kami melakukan latihan - kami bermain darurat, yang sekelompok administrator (semua pada gilirannya) harus menghilangkan menggunakan "Rencana Aksi Darurat". Administrator sistem terkemuka bergiliran menjalankan peran koordinator.
- Triwulan dalam mode uji, mengisolasi pusat data (semuanya pada gilirannya) melalui LAN dan WAN, yang memungkinkan Anda untuk mengidentifikasi kemacetan tepat waktu.
- Lebih sedikit bad drive, karena kami telah memperketat standar: jam operasional lebih sedikit, ambang batas yang lebih ketat untuk SMART,
- BerkeleyDB yang sepenuhnya ditinggalkan - database lama dan tidak stabil yang membutuhkan banyak waktu untuk pulih dari server restart.
- Kurangi jumlah server dengan MS SQL dan kurangi ketergantungan pada yang tersisa.
- Kami telah mendapatkan cloud kami sendiri - one-cloud , di mana kami telah secara aktif memigrasi semua layanan selama dua tahun terakhir. Awan sangat menyederhanakan seluruh siklus kerja dengan aplikasi, dan jika terjadi kecelakaan berikan alat unik seperti:
- benar hentikan semua aplikasi dalam satu klik;
- migrasi aplikasi sederhana dari server yang gagal;
- peringkat otomatis (dalam urutan prioritas layanan) meluncurkan pusat data secara keseluruhan.
Kecelakaan yang dijelaskan dalam artikel ini menjadi yang terbesar sejak hari ke 404. Tentu saja, tidak semuanya berjalan lancar. Misalnya, selama tidak dapat diaksesnya pusat data-burner di pusat data lain, disk menabrak salah satu server, yaitu, hanya satu dari tiga replika di cluster Cassandra yang tersedia, karena 4,2% pengguna aplikasi seluler tidak bisa masuk . Pada saat yang sama, pengguna yang sudah terhubung terus bekerja. Secara total, lebih dari 30 masalah diidentifikasi sesuai dengan hasil kecelakaan - dari bug dangkal hingga cacat arsitektur layanan.
Tetapi perbedaan utama antara kecelakaan saat ini dan yang ke-404 adalah bahwa sementara kami menghilangkan konsekuensi dari kebakaran, pengguna masih berkorespondensi dan melakukan panggilan video di
Tamtam , bermain game, mendengarkan musik, memberikan hadiah satu sama lain, menonton video, acara TV dan saluran TV di
OK , dan juga dialirkan ke
OK Live .
Bagaimana kecelakaanmu?