Eyvah! Storage'ın yazılımında "bug" çıktı!

Yönettiğim ortamların birinde disk altyapısı (storage) kaynaklı ciddi bir sorun oluştu. Şöyle bir senaryo düşünün ki, X veri merkezinde barındırdığımız canlı veritabanı ve uygulama sunucularımıza ait dosyaların ve yedeklerimizin bulunduğu disk altyapısı Y firmasının ürünü olan Storage'taki bir yazılım sorunu (bug) nedeniyle komple bozuluyor (corruption). Ne canlı ortam verilerine, ne de yedeklerine ulaşılamıyor. Tam bir kriz!

Bir süre sonra veri merkezi 1 gün öncesine ait veritabanı yedeklerine ulaşabildiğini söyledi, fakat bu bizim için 1 günlük veri kaybı demekti. Bu kritik bir sistem olduğu için tabii ki Transaction Log yedekleri alıyorduk ve bu yedek dosyaları da sistemi tamamen kaybetmeden 1 saat öncesine kadar geri getirilebildi. Bu noktada veri kaybı 1 saatti. Yine neyse ki bu ortamın BT yöneticisi felaket senaryolarının bilincindeydi ve bu konuda yatırım yapılmasını sağlamıştı, bu sayede başka bir veri merkezinde bulunan yedeklerimizi kullanarak yalnızca 1 dakikalık veri kaybı ile bu kriz atlatılmış oldu.

Not: Müşteri felaket önleme seçenekleri konusunda bilgilendirilmişti. Maliyet-fayda hesabına göre 1 dakikalık veri kaybı müşteri için kabul edilebilirdi.

Sadece son 2 senede 4 kere buna benzer durum için yedekliliğin önemine dair yazılar yazmışım (yazı1, yazı2, yazı3, yazı4), en azından bir çırpıda bulabildiklerim bunlar. Disk altyapıları kısmen veya tamamen yazılım (firmware) veya donanım hatası nedeniyle bozulabilir. Ayrıca verileriniz disk veya sistem yöneticileri tarafından yanlışlıkla silinebilir veya bir saldırı neticesinde bozulabilir. Sistemleriniz çeşitli nedenlerle kullanılamaz, ulaşılamaz duruma gelebilir. Bu gibi olasılıklar sizin başınıza gelmeyecek sanmayın, çok yanılırsınız. Türkiye'nin veya dünyanın en büyük kurumlarının bile başlarına geliyor bu durumlar. Şahsen yönettiğim ortamlarda ister istemez, şartlar ve imkanlar dahilindeki her türlü önleme rağmen bahsettiğim çeşitli nedenlerle senede ortalama 2 kere yaşıyorum benzer senaryoları. Şimdiye kadar bunu tatmadıysanız bile, üzgünüm ama emin olun eninde sonunda tadacaksınız. En iyisi, o güne şimdiden hazırlıklı olmak!

Size tavsiyem şirketiniz içerisindeki ilgili partilerle bir toplantı yapın ve şu soruların cevaplarını arayın: 

"Ne kadar sürelik veri kaybına tahammülümüz var? 1 gün? 1 saat? 1 dakika? Birkaç saniye?"

"Sistemimizin en fazla ne kadar süre kapalı kalmasını tolere edebiliriz?" 

Tabii ki iki soruya da ilk etapta "Sıfır!" yanıtının gelmesi şaşırtıcı olmayacak, fakat bunun maliyet-fayda hesabının yapılması gerekiyor. Çünkü kullandığınız SQL Server Edition'ına göre farklı lisans ücretleri ödüyorsunuz ve yine Edition'lara göre farklı sürekli kullanılabilirlik ve felaket önleme seçenekleri mevcut. İhtiyacınıza en uygun çözümü örneğin SQL Server'ın Standard Edition'ıyla da üretebilirsiniz, böylece lisans maliyetlerinizi hele ki dövizin bu seviyelerde olduğu bu zamanlarda ciddi oranda düşürebilirsiniz. Ayrıca şunu da belirtmek gerekir ki bütçe musluklarını açsanız bile çeşitli nedenlerle tamamen kesintisiz bir ortam kuramazsınız, fakat kesintinin olabildiğince kısa sürmesini ve doğru yönetilmesini sağlayabilirsiniz.

Veri kayıpsız, az kesintili günler dilerim.

Ekrem Önsoy
Microsoft SQL Server Danışmanı
www.ekremonsoy.com

2. Bölüm: Yedeklemeye gereken önemi vermek için canınızın yanması şart mı?

Bir önceki yazımda doğru yedeklemenin önemini vurgulamış, bir canlı ortamda disklerin silindiğini ve yedeklerden nasıl (neredeyse) hiç veri kaybetmeden geri döndüğümüzü bir sonraki yazımda anlatacağımı söylemiştim. Doğru yedeklemenin nasıl hayat kurtardığını somut bir örnekle bu yazımda anlatacağım.

1-2 ay önce ortamlardan birinde bir Cuma öğlen saat 14:30 gibi çok kritik olan bir canlı SQL Server sunucusundan ilginç mesajlar ve son kullanıcıdan şikayetler gelmeye başladı.

İlgili sunucuya bağlanmaya çalıştım, ama nafile. Ne SQL Server Management Studio ile bağlanabiliyordum ne de uzak masa üstü bağlantısı yapabiliyordum. Sunucu sanal bir sunucuydu. İlgili sistemci arkadaşımla temas kurdum ve şikayetimi ilettim. Az sonra sistemci arkadaşımdan telefon geldi ve telefondaki ses şöyle diyordu: "Diskleri kaybettik...".

Bir felaket senaryosunun yolunu açan ilk kelimelerdi bunlar. Daha fazla bilgiye ihtiyacım olduğu için doğrudan disk yöneticisi arkadaşlarla temas kurdum. Yeni bir disk verilmeye çalışılırken, varolan veritabanı Transaction Log, SQL Server ve işletim sistemi dosyalarının bulunduğu diskler silinmişti ve geri getirilme olasılığı yoktu. Sorunun teknik olmadığını ve insan hatasından kaynaklandığını öğrendikten sonra, sorun en azından o anda tekrar etmeyeceği için ilk etapta öğrenmek istediklerim sadece bunlardı. Neden ve nasıl olduğunun ayrıntıları bu etapta beni ilgilendirmiyordu, çünkü sorunun çözümüne hiçbir katkısı yoktu.

Sistemi geri ayağa kaldırabilmek için elimdeki seçeneklerimi düşündüm.
- Yerel sunucuda, veritabanlarının bulunduğu fiziksel disk altyapısından hariç başka bir disk altyapısından verilen disklere düzenli ve sık aldırdığım yedeklerim vardı,
- Uzakta Log Shipping ile beslediğim, tüm veritabanlarının ve Instance düzeyindeki nesnelerin olduğu bir yedek sunucum vardı,
- Alınan imaj yedekleri vardı (hatırlatırım, ortam sanal makine idi).

Buradaki en kilit madde 1. madde, o maddeyi birkaç kere okuyun lütfen. Eğer disk altyapıları fiziksel olarak farklı olmasaydı o zaman disk yönetimi bölümündeki arkadaş bu diskleri de silebilirdi, büyük risk. 2. madde bize ekstra bir yedekleme seçeneği sağlamıştı. Eğer 2. disk altyapısında da bir sıkıntı olsaydı, ODM ortamımıza yönelecektik.

Eldeki imkanları ve seçenekleri düşünerek hemen bir plan yaptık ve sıfırdan bir makine kurarak sistemi en kısa sürede tekrar ayağa kaldırdık. Eğer üzerinde düşünülmüş bir yedekleme planı olmasaydı, belki de şirket iş hayatına devam edemeyecekti.

Bazen gayet güzel bütçe imkanı oluyor, ama güzel yedekleme planları olmuyor. Biri olmadan, diğeri hiçbir işe yaramıyor. İyi bir felaketten kurtarma planı, hayat kurtarır.

Kazasız, belasız iyi işler dilerim,
Ekrem Önsoy

Yedeklemeye gereken önemi vermek için canınızın yanması şart mı?

Düşününce İstanbul'daki bir sonraki deprem için alınması gereken, alınıyormuş gibi gösterilen ama aslında alınmayan ve yedeklemeye verilmesi gereken, veriliyormuş gibi görünen ama aslında verilmeyen önem ve ciddiyet arasında ne kadar benzerlik olduğu geliyor aklıma. İstanbul'daki son büyük depremde ne kadar canımız yanmıştı, o kadar konuşuldu, yazıldı, çizildi... Sonuç? Önce sağda solda, içlerinde kazma kürek olduğu söylenen konteynırlar gördük, bir süre sonra yok oldular tek tek, sonra "Kentsel Dönüşüm" adı altında, sadece müteahhitlerin kar edebileceği binaların yenilendiği abuk bir çözüm çıktı ortaya. Altyapı, aynı. Maksadım elbette politik bir tartışma yaratmak değil, yedeklemeye dikkat çekmek.

Çünkü, efendim birçok firmada şahit oldum ve olmaya da devam ediyorum:

- "Yedekleme bizim için çok önemli!"

- "Yedekleme için Veaam, Data Protection Manager, Glasshouse gibi çeşitli çözümler kullanıyoruz."

- "Yedekleme araçlarımızdan sorumlu, kullanan personelimiz var."

- "Yedekleme için gerekli tüm kaynaklarımız var"

deniyor... Sonuç? Yıllardır biriktirdiğim tecrübeye dayanarak çok farklı ortamlardan, ama gerçek örneklerle anlatıyorum, sonuç şöyle:

- Çok daha kısa sürede alınabilecek yedeğin alınması 10 saat sürüyor,

- Veaam ile aynı veritabanlarının günde 8 kere yedeği alınıyor. VSS ile aldığı için gün içerisinde donmalara neden oluyor,

- Data Protection Manager (DPM) ile alındığı zannedilen yedek konusunda DPM yöneticisinin bile haberi yok,

- Yedekler, veritabanı ve diğer tüm dosyaların da bulunduğu aynı disk altyapısındaki disklere alınıyor. Yani disk altyapısı gitti mi, yedekler de gidiyor, asıl dosyalar da..

- Yedekler alınıyor, ama ne sıkıştırma özelliği kullanılıyor, ne "checksum" kontrolü yapılıyor. Bu nedenle yedek depolama maliyeti artıyor. Çok daha fazla yedek, daha uzun süre depolanabileceğine, çok daha az yedek daha kısa süreliğine tutulabiliyor. Sonra yenilerine yer açmak için eskiler, daha uzun süre tutulabilecekken siliniyorlar. Yani kaynaklar verimli kullanılmıyor,

- Çok kritik veritabanları için sadece bir kere tam veritabanı yedeği (full database backup) alınıyor, ama Transaction Log yedeği alınmıyor, yani bir kriz anında 24 saatlik veri kaybı olasılığı var,

- Restore testleri yapılmıyor veya yapılıyor, ama bir düzen yok. Restore testlerine gerekli önem verilmiyor,

- Hangi veritabanı ve sunucu ne kadar kritik? Hangisi için hangi yedek ne kadar süre tutulmalı? Ne kadar sürede geri dönüş sağlanmak zorunda? Ne kadarlık veri kaybı tolere edilebilir? RPO ve RTO'lar belirlenmemiş.

Ve daha neler neler... Nasıl? Size de bir şeyler hatırlattı mı yukarıdaki maddeler? Eminim birçok kişiye kendi ortamlarıyla ilgili bir şeyler çağrıştırmıştır.

Öyle veya böyle, üzgünüm ama o felaket bir gün başınıza gelecek ve felaketin binbir türlü çeşidi var. Disk altyapısı bozulabilir, yeni bir disk verilirken varolan canlı ortam diskleri silinebilir (daha 1,5 ay önce geldi başıma), Windows veya SQL Server Update'leri nedeniyle makine bir daha açılmayabilir veya servisler doğru çalışmayabilir (bu da 1 ay önce geldi başıma), bir çalışan yanlışlıkla veya kızgınlıkla verilerinizi bozabilir, güncelleyebilir veya silebilir...  Bunun için artık çok daha çeşitli, uygun fiyatlı seçenekler ve birçok şirketin bu seçenekleri kullanabilmesi için kaynak da var. Tek sorun, bu konuya vaktinde yeterince önem verilmemesi gibi geliyor bana. Vaktinde önem verilmeyince de, imkan da olsa, personel de olsa, artık iş işten geçmiş oluyor.

Doğru yedekleme politikası zamanı gelince hayat kurtarır. Bir sonraki yazımda, yukarıdaki paragrafta başıma gelen canlı ortam disklerinin silinmesinden ve doğru bir yedekleme politikasıyla neredeyse hiç veri kaybetmeden nasıl o ortamı kurtardığımızdan bahsedeceğim.

Sevgiler,

Ekrem Önsoy