Piye perasaanmu yen ing sawijining dina musim panas sing apik, pusat data karo peralatan katon kaya iki?
Halo kabeh! Jenengku Dmitry Samsonov, aku kerja minangka administrator sistem terkemuka ing "" Foto kasebut nuduhake salah siji saka papat pusat data ing ngendi peralatan sing nglayani proyek kita diinstal. Ing mburi tembok kasebut ana sekitar 4 ewu peralatan: server, sistem panyimpenan data, peralatan jaringan, lsp. - meh ⅓ kabeh peralatan kita.
Umume server yaiku Linux. Ana uga sawetara rolas server ing Windows (MS SQL) - warisan kita, sing wis ditinggalake kanthi sistematis sajrone pirang-pirang taun.
Dadi, tanggal 5 Juni 2019 jam 14:35, insinyur ing salah sawijining pusat data nglaporake weker geni.
Negasi
14:45. Kedadeyan asap cilik ing pusat data luwih umum tinimbang sing sampeyan pikirake. Indikator ing aula padha normal, supaya reaksi pisanan kita relatif kalem: padha ngenalaken larangan ing karya karo produksi, yaiku, ing sembarang owah-owahan konfigurasi, muter metu versi anyar, etc., kajaba kanggo karya related kanggo ndandani soko.
Bebendune
Apa sampeyan wis tau nyoba ngerteni saka petugas pemadam kebakaran persis ing endi geni kedadeyan ing atap, utawa mlebu menyang atap sing kobong dhewe kanggo netepake kahanan kasebut? Apa tingkat kapercayan ing informasi sing ditampa liwat limang wong?
14: 50. Informasi wis ditampa yen geni wis nyedhaki sistem pendingin. Nanging bakal teka? Administrator sistem sing tugas mbusak lalu lintas eksternal saka ngarep pusat data iki.
Ing wayahe, ngarep kabeh layanan kita diduplikasi ing telung pusat data, balancing digunakake ing tingkat DNS, sing ngidini kita mbusak alamat siji pusat data saka DNS, saéngga nglindhungi pangguna saka masalah potensial karo akses menyang layanan. . Yen masalah wis ana ing pusat data, bakal ninggalake rotasi kanthi otomatis. Sampeyan bisa maca liyane kene:
Geni durung kena pengaruh apa wae - ora ana pangguna utawa peralatan sing rusak. Apa iki kacilakan? Bagean pisanan saka dokumen "Rencana Tindakan Kecelakaan" nemtokake konsep "Kecelakaan", lan bagean kasebut rampung kaya iki:
«Yen ana keraguan apa ana kacilakan utawa ora, iku kacilakan!»
14:53. Koordinator darurat ditunjuk.
Koordinator yaiku wong sing ngontrol komunikasi antarane kabeh peserta, ngevaluasi skala kacilakan, nggunakake Rencana Tindakan Darurat, narik personel sing dibutuhake, ngawasi ngrampungake perbaikan, lan sing paling penting, utusan tugas apa wae. Ing tembung liyane, iki wong sing ngatur kabeh proses tanggap darurat.
Nyang-nyangan
15:01. Kita wiwiti mateni server sing ora ana hubungane karo produksi.
15:03. Kita mateni kabeh layanan sing wis dilindhungi kanthi bener.
Iki kalebu ora mung ngarep (sing saiki pangguna ora bisa ngakses maneh) lan layanan tambahan (logika bisnis, cache, lan sapiturute), nanging uga macem-macem database kanthi faktor replikasi 2 utawa luwih (, , , lsp).
15: 06. Informasi wis ditampa yen geni ngancam salah sawijining aula pusat data. Kita ora duwe peralatan ing kamar iki, nanging kasunyatan sing geni bisa nyebar saka gendheng menyang aula banget ngganti gambar apa mengkono.
(Iku mengko dadi metu sing ora ana ancaman fisik kanggo bale, awit iku hermetically nutup saka gendheng. Ancaman mung kanggo sistem cooling bale iki.)
15:07. Kita ngidini eksekusi printah ing server ing mode akselerasi tanpa mriksa tambahan ().
15:08. Suhu ing aula ana ing wates normal.
15: 12. Tambah ing suhu ing aula kacathet.
15:13. Luwih saka setengah saka server ing pusat data dipateni. Ayo diterusake.
15:16. Keputusan digawe kanggo mateni kabeh peralatan.
15:21. Kita wiwiti mateni daya menyang server stateless tanpa mateni aplikasi lan sistem operasi kanthi bener.
15:23. Klompok wong sing tanggung jawab kanggo MS SQL diparengake (ana sawetara wong, katergantungan layanan ing wong-wong mau ora gedhe, nanging prosedur kanggo mulihake fungsi njupuk maneh lan luwih rumit tinimbang, contone, Cassandra).
Depresi
15: 25. Informasi ditampa babagan daya dipateni ing papat aula saka 16 (No. 6, 7, 8, 9). Peralatan kita ana ing aula 7 lan 8. Ora ana informasi babagan loro bale kita (No. 1 lan 3).
Biasane, nalika kebakaran, sumber daya langsung dipateni, nanging ing kasus iki, amarga kerja koordinasi petugas pemadam kebakaran lan personel teknis pusat data, ora dipateni ing endi wae lan ora langsung, nanging yen perlu.
(Sabanjure ditemokake yen daya ora dipateni ing aula 8 lan 9.)
15:28. Kita miwiti masang database MS SQL saka serep ing pusat data liyane.
Suwene iku bakal njupuk? Apa kapasitas jaringan cukup kanggo kabeh rute?
15: 37. A mati sawetara bagéan saka jaringan direkam.
Manajemen lan jaringan produksi sacara fisik diisolasi saka siji liyane. Yen jaringan produksi kasedhiya, sampeyan bisa pindhah menyang server, mungkasi aplikasi lan mateni OS. Yen ora kasedhiya, sampeyan bisa mlebu liwat IPMI, mungkasi aplikasi lan mateni OS. Yen ora ana jaringan, sampeyan ora bisa nindakake apa-apa. "Matur nuwun, Cap!", sampeyan bakal mikir.
"Lan umume, ana akeh kerusuhan," sampeyan bisa uga mikir.
Masalahe yaiku server, sanajan tanpa geni, ngasilake panas sing akeh banget. Luwih tepate, nalika ana cooling, padha generate panas, lan nalika ora cooling, padha nggawe inferno neraka, kang paling apik bakal nyawiji bagéan saka peralatan lan mateni bagean liyane, lan ing paling awon ... nyebabake geni nang. bale, kang meh dijamin numpes kabeh.
15:39. Kita ndandani masalah karo database conf.
Basis data conf minangka backend kanggo layanan kanthi jeneng sing padha, sing digunakake dening kabeh aplikasi produksi kanggo ngganti setelan kanthi cepet. Tanpa basis iki, kita ora bisa ngontrol operasi portal, nanging portal kasebut bisa digunakake.
15:41. Sensor suhu ing piranti jaringan inti rekaman maca cedhak maksimum diijini. Iki minangka kothak sing ngemot kabeh rak lan njamin operasi kabeh jaringan ing tengah data.
15:42. Pelacak masalah lan wiki ora kasedhiya, pindhah menyang siyaga.
Iki dudu produksi, nanging yen ana kacilakan, kasedhiyan basis pengetahuan apa wae bisa dadi kritis.
15:50. Salah sawijining sistem ngawasi wis dipateni.
Ana sawetara wong, lan padha tanggung jawab kanggo macem-macem aspèk layanan. Sawetara dikonfigurasi supaya bisa digunakake kanthi otonom ing saben pusat data (yaiku, mung ngawasi pusat data dhewe), liyane kalebu komponen sing disebarake sing bisa urip kanthi transparan nalika ilang pusat data.
Ing kasus iki mandegake karya , sing beroperasi ing mode master-standby. Ngalih menyang siyaga.
Adopsi
15:51. Kabeh server kajaba MS SQL dipateni liwat IPMI tanpa mati kanthi bener.
Apa sampeyan siap kanggo manajemen server massive liwat IPMI yen perlu?
Wektu banget nalika nylametake peralatan ing pusat data rampung ing tahap iki. Kabeh sing bisa ditindakake wis rampung. Sawetara kolega bisa ngaso.
16: 13. Informasi wis ditampa manawa pipa freon saka AC bledosan ing atap - iki bakal nundha peluncuran pusat data sawise geni diilangi.
16:19. Miturut data sing ditampa saka staf teknis pusat data, kenaikan suhu ing aula wis mandheg.
17:10. Database conf wis dibalèkaké. Saiki kita bisa ngganti setelan aplikasi.
Napa iki penting banget yen kabeh iku fault-tolerant lan bisa malah tanpa siji pusat data?
Kaping pisanan, ora kabeh iku toleran fault. Ana macem-macem layanan sekunder sing durung bisa slamet saka kegagalan pusat data kanthi cukup, lan ana database ing mode master-standby. Kemampuan kanggo ngatur setelan ngijini sampeyan kanggo nindakake kabeh sing perlu kanggo nyilikake impact saka jalaran saka kacilakan ing pangguna malah ing kahanan angel.
Kapindho, dadi cetha yen operasi pusat data ora bakal dibalekake kanthi lengkap ing jam-jam sing bakal teka, mula kudu njupuk langkah-langkah kanggo mesthekake yen ora kasedhiya replika jangka panjang ora nyebabake masalah tambahan kayata disk lengkap ing pusat data sing isih ana.
17:29. Wektu pizza! Kita makaryakke wong, dudu robot.
Rehabilitasi
18:02. Ing aula No. 8 (kita), 9, 10 lan 11 suhu wis stabil. Salah siji sing tetep offline (No. 7) omah peralatan kita, lan suhu ing kono terus munggah.
18:31. Padha menehi go-ahead kanggo miwiti peralatan ing aula No.. 1 lan 3 - aula iki ora kena pengaruh dening geni.
Saiki, server diluncurake ing aula No. 1, 3, 8, diwiwiti kanthi sing paling kritis. Operasi sing bener kabeh layanan sing mlaku dicenthang. Isih ana masalah karo bale No.
18:44. Staf teknis pusat data nemokake yen ing kamar No. 7 (mung ana peralatan kita) akeh server sing ora dipateni. Miturut data kita, 26 server tetep online ing kana. Sawise mriksa kaping pindho, kita nemokake 58 server.
20:18. Teknisi pusat data nyebul hawa liwat kamar tanpa AC liwat saluran seluler sing mlaku liwat lorong.
23:08. Admin pisanan dikirim menyang omah. Ana sing kudu turu ing wayah wengi supaya bisa nerusake kerja sesuk. Sabanjure, kita bakal ngeculake sawetara admin lan pangembang liyane.
02:56. Kita ngluncurake kabeh sing bisa diluncurake. Kita nindakake akeh mriksa kabeh layanan nggunakake tes otomatis.
03:02. AC ing pungkasan, aula 7 wis dibalèkaké.
03:36. Kita nggawa ngarep ing pusat data menyang rotasi ing DNS. Saka wayahe lalu lintas pangguna wiwit teka.
Kita ngirim umume tim administrasi menyang omah. Nanging kita ninggalake sawetara wong.
FAQ cilik:
P: Apa sing kedadeyan saka 18:31 nganti 02:56?
A: Sawise "Rencana Tindakan Bencana", kita miwiti kabeh layanan, diwiwiti saka sing paling penting. Ing kasus iki, koordinator ing obrolan menehi layanan menyang administrator gratis, sing mriksa apa OS lan aplikasi wis diwiwiti, apa ana kesalahan, lan apa indikator kasebut normal. Sawise peluncuran rampung, dheweke nglaporake menyang chatting yen dheweke bebas lan nampa layanan anyar saka koordinator.
Proses luwih kalem dening hardware gagal. Sanajan mungkasi OS lan mateni server mlaku kanthi bener, sawetara server ora bali amarga tiba-tiba gagal disk, memori, lan sasis. Nalika daya ilang, tingkat kegagalan mundhak.
P: Napa sampeyan ora bisa mbukak kabeh bebarengan, banjur ndandani apa sing ana ing pemantauan?
A: Kabeh kudu ditindakake kanthi bertahap, amarga ana ketergantungan ing antarane layanan. Lan sampeyan kudu mriksa kabeh langsung, tanpa ngenteni ngawasi - amarga luwih apik kanggo ngatasi masalah kanthi cepet, tanpa ngenteni dadi luwih elek.
7:40. Admin (koordinator) pungkasan banjur turu. Dina kapisan karya wis rampung.
8:09. Pangembang pisanan, insinyur pusat data lan administrator (kalebu koordinator anyar) miwiti karya pemugaran.
09:37. Kita wiwit ngunggahake bale No.. 7 (sing pungkasan).
Ing wektu sing padha, kita terus mulihake apa sing ora tetep ing kamar liyane: ngganti disk / memori / server, ndandani kabeh sing "dibakar" ing ngawasi, ngalih peran maneh ing skema master-standby lan barang cilik liyane, sing ana. nanging cukup akeh.
17:08. Kita ngidini kabeh karya biasa karo produksi.
21:45. Karya dina kapindho rampung.
09:45. Dina iki dina Jumuah. Isih ana sawetara masalah cilik ing ngawasi. Minggu ngarep, kabeh wong pengin santai. We terus massively ndandani kabeh kita bisa. Tugas admin biasa sing bisa ditundha ditundha. Koordinator anyar.
15:40. Dumadakan setengah saka tumpukan peralatan jaringan inti ing pusat data LAIN diwiwiti maneh. Fronts dijupuk metu saka rotasi kanggo nyilikake resiko. Ora ana efek kanggo pangguna. Iku mengko ternyata sasis sing rusak. Koordinator lagi nggarap ndandani loro kacilakan bebarengan.
17:17. Operasi jaringan ing pusat data liyane wis dibalekake, kabeh wis dicenthang. Pusat data dilebokake ing rotasi.
18:29. Pakaryan dina katelu lan, ing umum, pemugaran sawise kacilakan wis rampung.
Afterword
04.04.2013 , "Kanca sekelas" - telung dina portal kasebut ora kasedhiya utawa sebagian ora kasedhiya. Sadawane wektu iki, luwih saka 100 wong saka kutha-kutha beda, saka perusahaan beda (many thanks maneh!), mbatalake lan langsung ing pusat data, kanthi manual lan otomatis, didandani ewu server.
Kita wis nggawe kesimpulan. Kanggo nyegah kedadeyan kasebut maneh, kita wis nindakake lan terus nindakake karya ekstensif nganti saiki.
Apa bedane utama antarane kacilakan saiki lan 404?
- Kita duwe "Rencana Tindakan Kecelakaan". Sawise seprapat, kita nganakake latihan - kita main ing kahanan darurat, sing kudu diilangi dening klompok pangurus (kabeh siji) nggunakake "Rencana Tindakan Darurat". Administrator sistem sing unggul dadi koordinator.
- Triwulanan, ing mode test, kita ngisolasi pusat data (kabeh siji) liwat jaringan LAN lan WAN, sing ngidini kita kanthi cepet ngenali bottlenecks.
- Disk sing rusak luwih sithik, amarga kita wis ngencengi standar: jam operasi luwih sithik, batesan sing luwih ketat kanggo SMART,
- Kita wis nilar BerkeleyDB, database lawas lan ora stabil sing mbutuhake wektu akeh kanggo pulih sawise server diwiwiti maneh.
- Kita nyuda jumlah server karo MS SQL lan nyuda katergantungan sing isih ana.
- Kita duwe dhewe , ngendi kita wis aktif migrasi kabeh layanan kanggo rong taun saiki. Awan kasebut nyederhanakake kabeh siklus nggarap aplikasi kasebut, lan yen ana kacilakan nyedhiyakake alat unik kayata:
- mandeg bener kabeh aplikasi ing siji klik;
- gampang migrasi aplikasi saka server sing gagal;
- peringkat otomatis (ing urutan prioritas layanan) Bukak kabeh pusat data.
Kacilakan sing diterangake ing artikel iki minangka sing paling gedhe wiwit dina kaping 404. Mesthi, ora kabeh lumaku kanthi lancar. Contone, nalika ora kasedhiya pusat data sing rusak ing geni ing pusat data liyane, disk ing salah sawijining server gagal, yaiku, mung siji saka telung replika ing kluster Cassandra sing bisa diakses, mulane 4,2% saka seluler pangguna aplikasi ora bisa mlebu. Ing wektu sing padha, pangguna sing wis disambungake terus kerja. Secara total, minangka akibat saka kacilakan kasebut, luwih saka 30 masalah diidentifikasi - saka kewan omo lan kekurangan ing arsitektur layanan.
Nanging prabédan paling penting antarane kacilakan saiki lan 404th yaiku nalika kita ngilangi akibat saka geni, pangguna isih ngirim SMS lan nelpon video menyang , main game, ngrungokake musik, menehi hadiah saben liyane, nonton video, serial TV lan saluran TV ing , lan uga stream ing .
Kepiye kacilakan sampeyan?
Source: www.habr.com