Veri merkezinin duman testinin alev alması durumunda sunucular söndürülmeli mi?

Güzel bir yaz gününde ekipmanlarınızın bulunduğu veri merkezi böyle görünse nasıl hissederdiniz?

Veri merkezinin duman testinin alev alması durumunda sunucular söndürülmeli mi?

Herkese selam! Adım Dmitry Samsonov, önde gelen sistem yöneticisi olarak çalışıyorum "Odnoklassniki" Fotoğraf, projemize hizmet veren ekipmanın kurulu olduğu dört veri merkezinden birini göstermektedir. Bu duvarların arkasında yaklaşık 4 bin parça ekipman var: sunucular, veri depolama sistemleri, ağ ekipmanları vb. - neredeyse tüm ekipmanlarımızın ⅓'ü.
Çoğu sunucu Linux'tur. Ayrıca Windows'ta (MS SQL) birkaç düzine sunucu var - uzun yıllardır sistematik olarak terk ettiğimiz mirasımız.
Böylece 5 Haziran 2019 saat 14:35'te veri merkezlerimizden birindeki mühendisler bir yangın alarmı bildirdi.

ret

14:45. Veri merkezlerinde küçük duman olayları düşündüğünüzden daha yaygındır. Salonların içindeki göstergeler normaldi, bu nedenle ilk tepkimiz nispeten sakindi: Bir şeyin düzeltilmesiyle ilgili işler dışında, üretimle çalışmayı, yani herhangi bir konfigürasyon değişikliğini, yeni sürümlerin piyasaya sürülmesini vb. Yasakladılar.

Öfke

Hiç itfaiyecilerden çatıda yangının tam olarak nerede çıktığını öğrenmeyi veya durumu değerlendirmek için yanan çatıya kendiniz çıkmayı denediniz mi? Beş kişiden alınan bilgiye güven derecesi ne olacak?

14: 50. Yangının soğutma sistemine yaklaştığı bilgisi geldi. Ama gelecek mi? Görevli sistem yöneticisi dış trafiği bu veri merkezinin ön kısmından uzaklaştırır.

Şu anda tüm hizmetlerimizin cepheleri üç veri merkezinde çoğaltılıyor, DNS düzeyinde dengeleme kullanılıyor, bu da bir veri merkezinin adreslerini DNS'den kaldırmamıza olanak tanıyor, böylece kullanıcıları hizmetlere erişimle ilgili olası sorunlardan koruyoruz . Veri merkezinde zaten sorun oluşmuşsa rotasyondan otomatik olarak ayrılır. Daha fazlasını buradan okuyabilirsiniz: Odnoklassniki'de yük dengeleme ve hata toleransı.

Yangın henüz bizi hiçbir şekilde etkilemedi; ne kullanıcılar ne de ekipmanlar zarar gördü. Bu bir kaza mı? “Kaza Eylem Planı” dokümanının ilk bölümünde “Kaza” kavramı tanımlanıyor ve bölüm şu şekilde bitiyor:
«Kaza olup olmadığı konusunda şüphe varsa kazadır!»

14:53. Acil durum koordinatörü atanır.

Koordinatör, tüm katılımcılar arasındaki iletişimi kontrol eden, kazanın boyutunu değerlendiren, Acil Durum Eylem Planını kullanan, gerekli personeli çeken, onarımların tamamlanmasını izleyen ve en önemlisi görevleri devreden kişidir. Başka bir deyişle acil müdahale sürecinin tamamını yöneten kişidir.

açık artırma

15:01. Üretimle ilgisi olmayan sunucuları devre dışı bırakmaya başlıyoruz.
15:03. Tüm ayrılmış hizmetleri doğru şekilde kapatıyoruz.
Bu, yalnızca ön cepheleri (bu noktada kullanıcılar artık erişemez) ve bunların yardımcı hizmetlerini (iş mantığı, önbellekler vb.) değil, aynı zamanda çoğaltma faktörü 2 veya daha fazlasına sahip çeşitli veritabanlarını da içerir (Kötü olayları önceden haber veren kimse, ikili veri depolama, soğuk depo, YeniSQL vesaire.).
15: 06. Veri merkezi salonlarından birinde yangının tehdit oluşturduğuna dair bilgi alındı. Bu odada ekipmanımız yok ama yangının çatıdan salonlara yayılabilmesi tabloyu büyük ölçüde değiştiriyor.
(Daha sonra çatıdan hava geçirmez şekilde kapatıldığı için salona yönelik fiziksel bir tehdit olmadığı ortaya çıktı. Tehdit yalnızca bu salonun soğutma sistemine yönelikti.)
15:07. Ek kontroller olmadan, hızlandırılmış modda sunucularda komut yürütülmesine izin veriyoruz (favori hesap makinemiz olmadan).
15:08. Salonlardaki sıcaklık normal sınırlar içerisinde.
15: 12. Salonlarda sıcaklıkta artış kaydedildi.
15:13. Veri merkezindeki sunucuların yarısından fazlası kapalı. Devam edelim.
15:16. Tüm ekipmanların kapatılmasına karar verildi.
15:21. Uygulamayı ve işletim sistemini doğru şekilde kapatmadan durum bilgisi olmayan sunucuların gücünü kapatmaya başlıyoruz.
15:23. MS SQL'den sorumlu bir grup insan tahsis edilmiştir (bunlardan çok azı vardır, hizmetlerin onlara bağımlılığı çok fazla değildir, ancak işlevselliği geri yükleme prosedürü daha fazla zaman alır ve örneğin Cassandra'dan daha karmaşıktır).

Депрессия

15: 25. 16 salonun 6'ünde (7, 8, 9, XNUMX) elektriğin kesildiği bilgisi geldi. Ekipmanlarımız 7 ve 8 numaralı salonlarda bulunmaktadır. İki salonumuz (1 ve 3 nolu) hakkında bilgi bulunmamaktadır.
Genellikle yangın sırasında güç kaynağı derhal kapatılır ancak bu durumda itfaiye ekiplerinin ve veri merkezi teknik personelinin koordineli çalışması sayesinde her yerde ve hemen değil, gerektiği gibi kapatılmıştır.
(Daha sonra 8. ve 9. salonlarda elektriğin kapatılmadığı keşfedildi.)
15:28. MS SQL veritabanlarını diğer veri merkezlerindeki yedeklerden dağıtmaya başlıyoruz.
Ne kadar sürer? Rotanın tamamı için yeterli ağ kapasitesi var mı?
15: 37. Ağın bazı bölümlerinin kapatıldığı kaydedildi.
Yönetim ve üretim ağı fiziksel olarak birbirinden izole edilmiştir. Üretim ağı mevcutsa sunucuya gidebilir, uygulamayı durdurabilir ve işletim sistemini kapatabilirsiniz. Mevcut değilse IPMI aracılığıyla giriş yapabilir, uygulamayı durdurabilir ve işletim sistemini kapatabilirsiniz. Ağlardan hiçbiri yoksa hiçbir şey yapamazsınız. “Teşekkürler Kaptan!” diye düşüneceksiniz.
"Ve genel olarak çok fazla kargaşa var" diye de düşünebilirsiniz.
Sorun şu ki, sunucular yangın olmasa bile çok büyük miktarda ısı üretiyor. Daha doğrusu, soğutma olduğunda ısı üretirler ve soğutma olmadığında cehennem gibi bir cehennem yaratırlar, bu da en iyi ihtimalle ekipmanın bir kısmını eritip diğer kısmını kapatır ve en kötü ihtimalle... salonun içinde her şeyi yok etmesi neredeyse garanti olan yangın.

Veri merkezinin duman testinin alev alması durumunda sunucular söndürülmeli mi?

15:39. Conf veritabanındaki sorunları düzeltiyoruz.

Conf veritabanı, tüm üretim uygulamaları tarafından ayarları hızlı bir şekilde değiştirmek için kullanılan aynı adlı hizmetin arka ucudur. Bu üs olmadan portalın çalışmasını kontrol edemeyiz ancak portalın kendisi çalışabilir.

15:41. Çekirdek ağ ekipmanındaki sıcaklık sensörleri, izin verilen maksimum değere yakın okumaları kaydeder. Bir rafın tamamını kaplayan ve veri merkezi içindeki tüm ağların çalışmasını sağlayan bir kutudur.

Veri merkezinin duman testinin alev alması durumunda sunucular söndürülmeli mi?

15:42. Sorun izleyici ve wiki kullanılamıyor, bekleme moduna geçin.
Bu üretim değildir ancak bir kaza durumunda herhangi bir bilgi tabanının mevcudiyeti kritik olabilir.
15:50. İzleme sistemlerinden biri kapandı.
Bunlardan birkaçı var ve hizmetlerin farklı yönlerinden sorumlular. Bunlardan bazıları her veri merkezinde otonom olarak çalışacak şekilde yapılandırılmıştır (yani yalnızca kendi veri merkezlerini izlerler), diğerleri ise herhangi bir veri merkezinin kaybından şeffaf bir şekilde kurtulabilen dağıtılmış bileşenlerden oluşur.
Bu durumda çalışmayı durdurdu iş mantığı göstergeleri anormallik tespit sistemiana bekleme modunda çalışır. Bekleme moduna geçildi.

Benimseme

15:51. MS SQL dışındaki tüm sunucular IPMI üzerinden doğru şekilde kapatılmadan kapatıldı.
Gerekirse IPMI aracılığıyla devasa sunucu yönetimine hazır mısınız?

Veri merkezindeki ekipmanların kurtarılmasının tamamlandığı an bu aşamadadır. Yapılabilecek her şey yapıldı. Bazı meslektaşlarımız dinlenebilir.
16: 13. Çatıda klimalardan gelen freon boruların patladığı bilgisi alındı ​​- bu, yangın giderildikten sonra veri merkezinin başlatılmasını geciktirecek.
16:19. Veri merkezinin teknik personelinden alınan verilere göre salonlardaki sıcaklık artışı durdu.
17:10. Conf veritabanı geri yüklendi. Artık uygulama ayarlarını değiştirebiliriz.
Her şey hataya dayanıklıysa ve tek bir veri merkezi olmadan bile çalışıyorsa bu neden bu kadar önemli?
Öncelikle her şey hataya dayanıklı değildir. Bir veri merkezi arızasından henüz yeterince kurtulamayan çeşitli ikincil hizmetler ve ana bekleme modundaki veritabanları vardır. Ayarları yönetme yeteneği, zor koşullarda bile bir kazanın sonuçlarının kullanıcılar üzerindeki etkisini en aza indirmek için gereken her şeyi yapmanıza olanak tanır.
İkinci olarak, veri merkezinin çalışmasının önümüzdeki saatlerde tam olarak eski haline getirilemeyeceği ortaya çıktı, bu nedenle kopyaların uzun süre kullanılamamasının, disklerin dolu olması gibi ek sorunlara yol açmamasını sağlamak için önlemler alınması gerekiyordu. kalan veri merkezleri.
17:29. Pizza Zamanı! Robotları değil insanları çalıştırıyoruz.

Veri merkezinin duman testinin alev alması durumunda sunucular söndürülmeli mi?

Rehabilitasyon

18:02. 8 numaralı salonlarda (bizimki), 9, 10 ve 11 numaralı salonlarda sıcaklık dengelendi. Çevrimdışı kalanlardan biri (No. 7) ekipmanlarımızı barındırıyor ve oradaki sıcaklık artmaya devam ediyor.
18:31. 1 ve 3 numaralı salonlardaki ekipmanların devreye alınmasına izin verdiler, bu salonlar yangından etkilenmedi.

Şu anda sunucular en kritik olanlardan başlamak üzere 1, 3, 8 numaralı salonlarda hizmete açılmaktadır. Çalışan tüm hizmetlerin doğru çalışıp çalışmadığı kontrol edilir. 7 numaralı salonda hala sorunlar var.

18:44. Veri merkezinin teknik personeli, 7 numaralı odada (yalnızca ekipmanlarımızın bulunduğu yer) birçok sunucunun kapatılmadığını keşfetti. Verilerimize göre orada 26 sunucu çevrimiçi kalıyor. İkinci bir kontrolden sonra 58 sunucu buluyoruz.
20:18. Veri merkezi teknisyenleri, koridorlardan geçen hareketli kanallar aracılığıyla klimasız bir odaya hava üflüyor.
23:08. İlk yönetici eve gönderildi. Birisinin yarın işe devam edebilmesi için gece uyuması gerekiyor. Daha sonra birkaç yönetici ve geliştirici daha yayınlayacağız.
02:56. Başlatılabilecek her şeyi başlattık. Otomatik testler kullanarak tüm hizmetleri birçok kez kontrol ediyoruz.

Veri merkezinin duman testinin alev alması durumunda sunucular söndürülmeli mi?

03:02. Son 7. salondaki klimalar yenilenmiştir.
03:36. Veri merkezindeki cepheleri DNS’de rotasyona aldık. Bu andan itibaren kullanıcı trafiği gelmeye başlar.
İdari ekibin çoğunu evlerine gönderiyoruz. Ama birkaç kişiyi geride bırakıyoruz.

Küçük SSS:
Soru: 18:31'den 02:56'ya kadar ne oldu?
C: “Afet Eylem Planı” doğrultusunda en önemlilerinden başlayarak tüm hizmetlerimizi devreye alıyoruz. Bu durumda, sohbetteki koordinatör, hizmeti, işletim sisteminin ve uygulamanın başlatılıp başlatılmadığını, herhangi bir hata olup olmadığını ve göstergelerin normal olup olmadığını kontrol eden ücretsiz bir yöneticiye verir. Lansman tamamlandıktan sonra sohbete özgür olduğunu ve koordinatörden yeni bir hizmet aldığını bildirir.
Arızalı donanım nedeniyle süreç daha da yavaşlar. İşletim sisteminin durdurulması ve sunucuların kapatılması doğru bir şekilde gerçekleşse bile bazı sunucular disk, bellek ve kasadaki ani arızalar nedeniyle geri dönmemektedir. Güç kesildiğinde arıza oranı artar.
S: Neden her şeyi bir kerede çalıştırıp ardından izleme sırasında ortaya çıkan sorunları düzeltemiyorsunuz?
C: Hizmetler arasında bağımlılıklar olduğundan her şeyin aşamalı olarak yapılması gerekiyor. Ve izlemeyi beklemeden her şey hemen kontrol edilmelidir - çünkü sorunların daha da kötüleşmesini beklemeden hemen ele almak daha iyidir.

7:40. Son yönetici (koordinatör) yatmaya gitti. İlk günün çalışmaları tamamlandı.
8:09. İlk geliştiriciler, veri merkezi mühendisleri ve yöneticileri (yeni koordinatör dahil) restorasyon çalışmalarına başladı.
09:37. 7 numaralı salonu (sonuncusu) yükseltmeye başladık.
Aynı zamanda, diğer odalarda düzeltilmeyenleri geri yüklemeye devam ediyoruz: diskleri/belleği/sunucuları değiştirmek, izlemede "yanan" her şeyi düzeltmek, ana-yedek planlarında rolleri yeniden değiştirmek ve diğer küçük şeyler yine de oldukça fazla.
17:08. Üretimle ilgili tüm düzenli çalışmalara izin veriyoruz.
21:45. İkinci günün çalışmaları tamamlandı.
09:45. Bugün Cuma. İzlemede hala birkaç küçük sorun var. Hafta sonu yaklaşıyor, herkes rahatlamak istiyor. Elimizden gelen her şeyi büyük ölçüde onarmaya devam ediyoruz. Ertelenebilecek normal yönetici görevleri ertelendi. Koordinatör yeni.
15:40. Aniden BAŞKA bir veri merkezindeki Çekirdek ağ ekipmanı yığınının yarısı yeniden başlatıldı. Riskleri en aza indirmek için ön kısımlar rotasyondan çıkarıldı. Kullanıcılar için herhangi bir etkisi yoktur. Daha sonra arızalı bir şasi olduğu ortaya çıktı. Koordinatör iki kazanın birden onarılması için çalışıyor.
17:17. Başka bir veri merkezindeki ağ çalışması geri yüklendi, her şey kontrol edildi. Veri merkezi rotasyona tabi tutulur.
18:29. Kaza sonrası üçüncü gün çalışmaları ve genel olarak restorasyon çalışmaları tamamlandı.

Послесловие

04.04.2013, 404 hatasının olduğu gün, "Sınıf arkadaşları" En büyük kazayı atlattı — üç gün boyunca portal tamamen veya kısmen kullanılamıyordu. Tüm bu zaman boyunca, farklı şehirlerden, farklı şirketlerden 100'den fazla kişi (tekrar çok teşekkürler!), uzaktan ve doğrudan veri merkezlerinde, manuel ve otomatik olarak binlerce sunucuyu onardı.
Sonuçlar çıkardık. Bunun bir daha yaşanmaması için bugüne kadar kapsamlı çalışmalar yaptık ve yürütmeye devam ediyoruz.

Mevcut kaza ile 404 arasındaki temel farklar nelerdir?

  • “Kaza Eylem Planımız” var. Üç ayda bir tatbikatlar yapıyoruz - bir grup yöneticinin (hepsi sırayla) "Acil Durum Eylem Planı"nı kullanarak ortadan kaldırması gereken bir acil durum rolü oynuyoruz. Önde gelen sistem yöneticileri sırayla koordinatör rolünü üstlenirler.
  • Üç ayda bir, test modunda, veri merkezlerini (hepsi sırayla) LAN ve WAN ağları üzerinden izole ediyoruz, bu da darboğazları anında tespit etmemize olanak sağlıyor.
  • Standartları sıkılaştırdığımız için daha az bozuk disk: daha az çalışma saati, SMART için daha katı eşikler,
  • Sunucu yeniden başlatıldıktan sonra kurtarılması çok zaman alan eski ve dengesiz bir veritabanı olan BerkeleyDB'yi tamamen terk ettik.
  • MS SQL'li sunucu sayısını azalttık ve kalan sunuculara bağımlılığı azalttık.
  • Bizim kendimiz var bulut - tek bulutİki yıldır tüm hizmetleri aktif olarak taşıdığımız yer. Bulut, uygulamayla çalışma döngüsünün tamamını büyük ölçüde basitleştirir ve bir kaza durumunda aşağıdaki gibi benzersiz araçlar sağlar:
    • tek tıklamayla tüm uygulamaların doğru şekilde durdurulması;
    • uygulamaların arızalı sunuculardan kolay geçişi;
    • tüm veri merkezinin otomatik olarak derecelendirilmiş (hizmetlerin öncelik sırasına göre) başlatılması.

Bu yazıda anlatılan kaza 404. günden bu yana yaşanan en büyük kazaydı. Elbette her şey yolunda gitmedi. Örneğin, yangın mağduru veri merkezinin başka bir veri merkezinde kullanılamaması sırasında sunuculardan birindeki disk arızalandı, yani Cassandra kümesindeki üç kopyadan yalnızca biri erişilebilir kaldı, bu nedenle mobil uygulamanın %4,2'si kullanıcılar giriş yapamadı. Aynı zamanda halihazırda bağlı olan kullanıcılar çalışmaya devam etti. Kaza sonucunda, sıradan hatalardan hizmet mimarisindeki eksikliklere kadar toplamda 30'dan fazla sorun tespit edildi.

Ama şu anki kaza ile 404'üncü kaza arasındaki en önemli fark, biz yangının sonuçlarını ortadan kaldırırken kullanıcıların hala mesaj atıp görüntülü görüşme yapmasıydı. Tam tam, oyun oynadık, müzik dinledik, birbirimize hediyeler verdik, video, dizi ve TV kanalları izledik. Tamamve aynı zamanda akış olarak da yayınlandı Tamam Canlı.

Kazalarınız nasıl gidiyor?

Kaynak: habr.com

Yorum ekle