Microsoft Azure sanal makinelerinizde kullandığınız Standard Storage (HDD)'lerdeki TRIM özelliğinden haberdar mısınız? Eğer değilseniz, Microsoft Azure'da sanal diskleriniz varsa ve Storage maliyetlerinizi düşürmek istiyorsanız okumaya devam edin.
Efendim artık öyle veya böyle bulut projelerine bulaşmak kaçınılmaz oldu. Bu konuda da edindiğim tecrübe ve bilgileri olabildiğince sizlerle paylaşıyor olacağım.
Bu aralar benim de dahil olduğum bir Azure projesinde çalışırken oluşturulan bazı disklerde TRIM kullanılmadığını gördüm. Eğer TRIM kullanılmazsa ne mi olur? Diskiniz için ne kadar alan tanımlandıysa, ki bu alan miktarı an itibariyle azami 1TB'tır, o kadar alan boyutu için ücretlendirilirsiniz. Fakat o disk için TRIM özelliği etkinleştirilmişse, o zaman sadece o diskte kullandığınız alanlar kadar ücretlendirilirsiniz.
Misal yeni veya varolan bir sanal makineniz için 1TB boyutunda bir Standard Storage disk oluşturdunuz ve kullanmaya başladınız. Bu diskteki dosya veya dosyalar sabit belli bir boyutta değil, zaman zaman büyüyor, zaman zaman küçülüyor. İşte özellikle böyle senaryolar için TRIM özelliğini kullanırsanız Azure faturanız azalır.
Peki TRIM özelliğinin etkin olup olmadığını nasıl anlayabilirsiniz? Diskin bağlı olduğu sanal makineye bağlanın ve Command Prompt'tan aşağıdaki komutu çalıştırın:
fsutil behavior query DisableDeleteNotify
Eğer yukarıdaki komut sonuç olarak 0 döndürüyorsa o zaman TRIM etkin demektir, eğer sonuç olarak 1 dönüyorsa o zaman TRIM etkin değildir. TRIM'i etkinleştirmek için aşağıdaki komutu çalıştırabilirsiniz.
fsutil behavior set DisableDeleteNotify 0
Kaynak:
https://docs.microsoft.com/en-us/azure/virtual-machines/virtual-machines-windows-attach-disk-portal?toc=%2fazure%2fvirtual-machines%2fwindows%2ftoc.json
Ekrem Önsoy
26 Aralık 2016 Pazartesi
19 Aralık 2016 Pazartesi
Varolan donanım kaynaklarınızı gerçekten verimli kullanıyor musunuz?
Microsoft SQL Server ürününün, eski önyargılar nedeniyle birçok yönetici gözünde doğru yerde olmadığını düşünüyorum. Evet SQL Server eskiden, özellikle 2000 ve öncesi versiyonlarda gerçekten çok ilkeldi. Birçok sıkıntıları vardı. Özellikle SQL Server 2005 ile başlayan ve gün itibariyle gelinen noktada SQL Server 2016 ve Azure ile çok daha farklı bir noktada. Bunu 10.000+ kullanıcılı bir ortamda SQL Server 2000 kullanan biri olarak rahatlıkla söyleyebilirim.
Böyle bir giriş yapmamın nedeni, geçenlerde büyük bir firmanın yöneticisinin masaya oturduğu anda bana şöyle demesi:
- "Biliyorum, SQL Server zaten performanslı çalışmayan bir ürün, haliyle Oracle seviyesinde performans alabilmemiz için daha fazla donanıma ihtiyacı var."
- "Bu kadar geçmişte kaldığınız için üzgünüm bayım, ama bu çok demode bir fikir!" diyemedim ne yazık ki, ortam müsait değildi.
İpucu: İlgili firmada sadece birkaç günlük bir çalışma ile %66 performans iyileştirmesi sağladık!
Eğer bugün hala SQL Server veritabanlarınızdaki performanstan şikayetçiyseniz, ilk bakacağınız şeyler veritabanı sunucunuzun yapılandırılması / kurgusu, en iyi pratiklerin uygulanıp uygulanmadığı ve uygulamalarınızın çalıştırdığı veritabanı kodlarının "performans" özelliği ile birlikte yazılıp yazılmaması olmalı. Yazılımlar KOBİ'dekilerden büyük firmadakilere kadar daha ziyade "işlev" odaklı kod yazılıyor. Genellikle "Ekran benim makinemde / test ortamında iş tarafından talep edildiği gibi çalışıyor, kafi!" düşüncesi hakim. Maalesef hala birçok kurumda yazılım yazılırken "performans" ve "güvenlik" konuları birer özellik olarak görülmüyor. Neyse, bunlar belki başka bir yazının veya başka bir yazarın konusu. Bu yazımda başka bir konuya değineceğim.
Efendim SQL Server 2012 Standard Edition olan kritik ortamlardan birinde SQL Server sunucusunun CPU yapılandırmasında bir ilginçlik gördüm. Durum aşağıdaki gibiydi:
Daha sonra kullanım dışı (OFFLINE) görünen 4 ve 5 numaralı CPU soketlerini başka bir yolla daha kontrol ettim:
Bu makinede 6 tane CPU soket, her sokette de 2'şer tane Core var görünüyordu. Yani toplamda 12 Core vardı.
Bu ortamdaki Log'larda şöyle bir mesaj görüyordum:
"SQL Server detected 6 sockets with 2 cores per socket and 2 logical processors per socket, 12 total logical processors; using 8 logical processors based on SQL Server licensing. This is an informational message; no user action is required."
Yani makinede 12 Core olmasına rağmen, SQL Server bunun 8'ini görebiliyor, CPU kaynaklarının %33'ünden faydalanılamıyordu. Neden mi? Çünkü SQL Server 2012 Standard Edition'ın 4 soket lisanslama sınırlaması var. SQL Server 2012 Standard Edition'da 4'ten fazla CPU Soketi, 16'dan fazla Core kullanılamaz. Sonuç olarak israf edilen %33'lük bir CPU donanımı söz konusu, ama ilgili yöneticiler SQL Server'ın tüm varolan kaynağı kullandığını düşünüyor. Emin olabilirsiniz, daha farklı ortamlarda bundan çok çok daha büyük israf oranlarını gördüm.
İlave örnek: İsraf oranlarının nereye varabileceği hakkında sadece fikir vermesi açısından aşağıdaki mesaja bakın bir de, ama o hikayenin ayrıntılarına burada girmeyeceğim. Bu bir kurgu değildir, gerçek bir ortam.
SQL Server detected 8 sockets with 8 cores per socket and 8 logical processors per socket, 64 total logical processors; using 20 logical processors based on SQL Server licensing. This is an informational message; no user action is required.
Nasıl ama? CPU kaynaklarının %68,75'i SQL Server tarafından kullanılamıyor.
Asıl hikayemize dönersek, söz konusu makine bir sanal makineydi, ben de ilgili sistem yöneticilerine bu sanal makinenin CPU ayarlarının SQL Server lisanslaması açısından doğru olmadığını, değiştirmemiz gerektiğini ilettim. Ufak bir planlı kesintiyle, artık SQL Server makinedeki 12 Core'dan yani CPU kaynaklarının tümünden faydalanabiliyordu. SQL Server için herhangi bir CPU modelini kullanmamalısınız. Bir SQL Server sunucu için CPU seçimi özenle yapılmalıdır. Makinenin sanal veya fiziksel oluşu da dikkate alınmalıdır. Bu sadece performans açısından değil, lisanslama maliyeti açısından da çok önemlidir. Sırf yapacağınız yanlış bir CPU modeli seçimiyle bile işe onbinlerce dolar zararla başlayabilirsiniz.
Bu yapılandırma işinin tabii ki daha hafıza, disk ve ağ altyapısı ayakları var. Sonra da veritabanı tasarımı ve kodlar...
Demem o ki söylenmek, kızmak kolay; ama gerçekten de ürün mü sıkıntılı, yoksa hakkını veremeyenler mi? Birçok yönetici giderleri kısmak için yollar arıyor, ama "varolan kaynaklardan gerçekten verimli yararlanılabiliyor mu?" sorusu sorulmuyor.
Eğer sizin de farkında olduğunuz veya kuşkulandığınız benzer sorunlarınız varsa iletişime geçmek için beklemeyin.
İyi işler!
Ekrem Önsoy
Böyle bir giriş yapmamın nedeni, geçenlerde büyük bir firmanın yöneticisinin masaya oturduğu anda bana şöyle demesi:
- "Biliyorum, SQL Server zaten performanslı çalışmayan bir ürün, haliyle Oracle seviyesinde performans alabilmemiz için daha fazla donanıma ihtiyacı var."
- "Bu kadar geçmişte kaldığınız için üzgünüm bayım, ama bu çok demode bir fikir!" diyemedim ne yazık ki, ortam müsait değildi.
İpucu: İlgili firmada sadece birkaç günlük bir çalışma ile %66 performans iyileştirmesi sağladık!
Eğer bugün hala SQL Server veritabanlarınızdaki performanstan şikayetçiyseniz, ilk bakacağınız şeyler veritabanı sunucunuzun yapılandırılması / kurgusu, en iyi pratiklerin uygulanıp uygulanmadığı ve uygulamalarınızın çalıştırdığı veritabanı kodlarının "performans" özelliği ile birlikte yazılıp yazılmaması olmalı. Yazılımlar KOBİ'dekilerden büyük firmadakilere kadar daha ziyade "işlev" odaklı kod yazılıyor. Genellikle "Ekran benim makinemde / test ortamında iş tarafından talep edildiği gibi çalışıyor, kafi!" düşüncesi hakim. Maalesef hala birçok kurumda yazılım yazılırken "performans" ve "güvenlik" konuları birer özellik olarak görülmüyor. Neyse, bunlar belki başka bir yazının veya başka bir yazarın konusu. Bu yazımda başka bir konuya değineceğim.
Efendim SQL Server 2012 Standard Edition olan kritik ortamlardan birinde SQL Server sunucusunun CPU yapılandırmasında bir ilginçlik gördüm. Durum aşağıdaki gibiydi:
 |
| 6 tane CPU soketi görünüyor, 2 tanesi kullanım dışı |
Bu makinede 6 tane CPU soket, her sokette de 2'şer tane Core var görünüyordu. Yani toplamda 12 Core vardı.
Bu ortamdaki Log'larda şöyle bir mesaj görüyordum:
"SQL Server detected 6 sockets with 2 cores per socket and 2 logical processors per socket, 12 total logical processors; using 8 logical processors based on SQL Server licensing. This is an informational message; no user action is required."
Yani makinede 12 Core olmasına rağmen, SQL Server bunun 8'ini görebiliyor, CPU kaynaklarının %33'ünden faydalanılamıyordu. Neden mi? Çünkü SQL Server 2012 Standard Edition'ın 4 soket lisanslama sınırlaması var. SQL Server 2012 Standard Edition'da 4'ten fazla CPU Soketi, 16'dan fazla Core kullanılamaz. Sonuç olarak israf edilen %33'lük bir CPU donanımı söz konusu, ama ilgili yöneticiler SQL Server'ın tüm varolan kaynağı kullandığını düşünüyor. Emin olabilirsiniz, daha farklı ortamlarda bundan çok çok daha büyük israf oranlarını gördüm.
İlave örnek: İsraf oranlarının nereye varabileceği hakkında sadece fikir vermesi açısından aşağıdaki mesaja bakın bir de, ama o hikayenin ayrıntılarına burada girmeyeceğim. Bu bir kurgu değildir, gerçek bir ortam.
SQL Server detected 8 sockets with 8 cores per socket and 8 logical processors per socket, 64 total logical processors; using 20 logical processors based on SQL Server licensing. This is an informational message; no user action is required.
Nasıl ama? CPU kaynaklarının %68,75'i SQL Server tarafından kullanılamıyor.
Asıl hikayemize dönersek, söz konusu makine bir sanal makineydi, ben de ilgili sistem yöneticilerine bu sanal makinenin CPU ayarlarının SQL Server lisanslaması açısından doğru olmadığını, değiştirmemiz gerektiğini ilettim. Ufak bir planlı kesintiyle, artık SQL Server makinedeki 12 Core'dan yani CPU kaynaklarının tümünden faydalanabiliyordu. SQL Server için herhangi bir CPU modelini kullanmamalısınız. Bir SQL Server sunucu için CPU seçimi özenle yapılmalıdır. Makinenin sanal veya fiziksel oluşu da dikkate alınmalıdır. Bu sadece performans açısından değil, lisanslama maliyeti açısından da çok önemlidir. Sırf yapacağınız yanlış bir CPU modeli seçimiyle bile işe onbinlerce dolar zararla başlayabilirsiniz.
Bu yapılandırma işinin tabii ki daha hafıza, disk ve ağ altyapısı ayakları var. Sonra da veritabanı tasarımı ve kodlar...
Demem o ki söylenmek, kızmak kolay; ama gerçekten de ürün mü sıkıntılı, yoksa hakkını veremeyenler mi? Birçok yönetici giderleri kısmak için yollar arıyor, ama "varolan kaynaklardan gerçekten verimli yararlanılabiliyor mu?" sorusu sorulmuyor.
Eğer sizin de farkında olduğunuz veya kuşkulandığınız benzer sorunlarınız varsa iletişime geçmek için beklemeyin.
İyi işler!
Ekrem Önsoy
14 Aralık 2016 Çarşamba
Microsoft Güvenlik Zirvesi
Bugün sabahtan öğlene kadar Sakıp Sabancı Müzesi'nde, Microsoft'un düzenlediği Güvenlik Zirvesi etkinliğindeydim.
Bu etkinliğe katılmak istememin nedeni özellikle yeni çıkan veya gelişmekte olan Microsoft güvenlik teknolojilerinden ziyade, Kişisel Verilerin Korunma Kanunu (6689 numaralı kanun) hakkında bilgi edinmekti. "Bir kanun hakkında bilgi edinmek için neden bir Microsoft etkinliğine katılıyorsun ki?" diye bir soru gelebilir tabii akla mantıklı olarak. Biliyorsunuz Microsoft'un bir bulut çözümü var Azure (ki bu konuda size bir sürprizim olacak yakında!), birçok müşteri Kişisel Verilerin Korunması kanunu çerçevesinde verilerini bir bulut ortamına koymaya çekiniyor. Microsoft da Azure'a ciddi yatırım yapıyor ve (bazen biraz agresif bir şekilde de olsa) kullanılmasını istiyor. Bu nedenle bu kanunun verilerimizi Azure veya herhangi bir bulut ortamına koymaya engel olup olmadığını herkesten çok Microsoft ve benzer sektördeki firmalar araştırıyordur diye düşünüyorum.
Peki ben neden Kişisel Verilerin Korunma Kanunu ile bu kadar ilgileniyorum? Bu kanun çerçevesinde verilerden biz de sorumlu oluyoruz arkadaşlar. Birçok müşteri ile çalışıyoruz. Hem müşterilerimde bu konuda bir farkındalık yaratmak, hem de bu konudaki hukuki yükümlülüklerimizi daha iyi bilmek ve anlamak istediğimden bu kanun beni doğrudan ilgilendiriyor. Eğer bu yazıyı okuyorsanız, muhtemelen sizi de ilgilendiriyor!
Yine anladım ki Kişisel Verilerin Korunması Kanunu henüz daha emekleme aşamasında. Birçok net olmayan yer var, soru işaretleri var. Kanun çerçevesinde bir kurulun belirlenmesi ve bu kurulun da bazı şeyleri belirlemesi gerekiyor. Fakat henüz kurul tamamen belirlenmiş değil. Bu nedenle bu kanunda kurulun belirleyeceği söylenen bazı şeyler belirlenemiyor. Bunlar belirlenemediği için de bahsettiğim muğlaklıklar oluyor. Sonuç olarak Microsoft dahil, konu ile ilgilenen herkes sabırsızlıkla bu kurulun seçilmesini ve görevini yerine getirmesini bekliyor!
Efendim edindiğim diğer bilgilerden de bazılarını aktarayım. Öncelikle seminerde veriler bilgilere göre Türkiye'de internet kullanıcısı 46 milyon civarındaymış. Türkiye'deki cihazlarda bulunan zararlı uygulamalar (Malware) dünya ortalamasına göre 2 kat fazlaymış.
Bir çalışmaya göre kötü niyetli bir kullanıcı bir şirketteki kullanıcılara zararlı içerik olan bir e-posta gönderdiğinde, 100 kişiden 6'sının gelen e-postadaki ekli dosyaları açtığı belirtlenmiş. Bu kadar çok Bot olmasının, zararlı uygulamaların bu kadar yaygın olmasının ve her geçen gün daha fazla şirketin sunucu ve bilgisayarlarının fidye isteyen korsanlar tarafından ele geçirilmesine şaşmamalı.
Etkinlik sırasında konuşmacılardan birisi, büyük bir şirketin CEO'sunun kendisine anlattığı yaşanmış bir olaydan bahsetti. O büyük şirkette çalışan bir mühendisin gelen ekli bir e-postayı açması neticesinde sunucu, fidye isteyen bir yazılımca kitlenmiş. Çok büyük bir fidye karşılığı kilidi açmayı başarmışlar. Fakat aynı kişi o fidye yazılımının nasıl çalıştığını merak etmiş ve tekrar çalıştırınca aynı fidyeyi yine ödemek zorunda kalmışlar. Konuşmacı bunu anlatırken dinlemeliydiniz, çok güldük.
Yukarıda bahsettiğim gibi doğrudan bize yansımayan başka birçok çeşit ihlal var. Firmaların bu ihlalleri keşfetmesi ortalama 200 gün sürüyormuş. Tabii 200 güne kadar olan oluyor. Yani veritabanınıza sızıldıysa oradaki veriler sızdırılabiliyor veya değiştirilebiliyor veya aklınıza ne gelirse artık, çünkü bu noktada tamamen korsanın insafına kalıyorsunuz.
Veritabanı bazında güvenlik sadece Login oluşturmak/silmek, Ali ve Ayşe'yi X rolünün üyesi yapmak veya yapmamakla sağlanmıyor arkadaşlar. Bu konuda çok daha etraflıca düşünmeniz gerekiyor. Artık her zamankinden çok daha fazla sorumluluğumuz var. Kötü niyetli kişiler kadar çeşitli ve hızlı çözüm geliştiremediğiniz noktada, geri kalıyorsunuz ve hem kendinizi hem de verilerinizi tehlikeye atıyorsunuz. Aman dikkat!
Hayırlı işler,
Ekrem Önsoy
Bu etkinliğe katılmak istememin nedeni özellikle yeni çıkan veya gelişmekte olan Microsoft güvenlik teknolojilerinden ziyade, Kişisel Verilerin Korunma Kanunu (6689 numaralı kanun) hakkında bilgi edinmekti. "Bir kanun hakkında bilgi edinmek için neden bir Microsoft etkinliğine katılıyorsun ki?" diye bir soru gelebilir tabii akla mantıklı olarak. Biliyorsunuz Microsoft'un bir bulut çözümü var Azure (ki bu konuda size bir sürprizim olacak yakında!), birçok müşteri Kişisel Verilerin Korunması kanunu çerçevesinde verilerini bir bulut ortamına koymaya çekiniyor. Microsoft da Azure'a ciddi yatırım yapıyor ve (bazen biraz agresif bir şekilde de olsa) kullanılmasını istiyor. Bu nedenle bu kanunun verilerimizi Azure veya herhangi bir bulut ortamına koymaya engel olup olmadığını herkesten çok Microsoft ve benzer sektördeki firmalar araştırıyordur diye düşünüyorum.
Peki ben neden Kişisel Verilerin Korunma Kanunu ile bu kadar ilgileniyorum? Bu kanun çerçevesinde verilerden biz de sorumlu oluyoruz arkadaşlar. Birçok müşteri ile çalışıyoruz. Hem müşterilerimde bu konuda bir farkındalık yaratmak, hem de bu konudaki hukuki yükümlülüklerimizi daha iyi bilmek ve anlamak istediğimden bu kanun beni doğrudan ilgilendiriyor. Eğer bu yazıyı okuyorsanız, muhtemelen sizi de ilgilendiriyor!
 |
| Etkinliğin yapıldığı salondan bir görüntü |
Yine anladım ki Kişisel Verilerin Korunması Kanunu henüz daha emekleme aşamasında. Birçok net olmayan yer var, soru işaretleri var. Kanun çerçevesinde bir kurulun belirlenmesi ve bu kurulun da bazı şeyleri belirlemesi gerekiyor. Fakat henüz kurul tamamen belirlenmiş değil. Bu nedenle bu kanunda kurulun belirleyeceği söylenen bazı şeyler belirlenemiyor. Bunlar belirlenemediği için de bahsettiğim muğlaklıklar oluyor. Sonuç olarak Microsoft dahil, konu ile ilgilenen herkes sabırsızlıkla bu kurulun seçilmesini ve görevini yerine getirmesini bekliyor!
Efendim edindiğim diğer bilgilerden de bazılarını aktarayım. Öncelikle seminerde veriler bilgilere göre Türkiye'de internet kullanıcısı 46 milyon civarındaymış. Türkiye'deki cihazlarda bulunan zararlı uygulamalar (Malware) dünya ortalamasına göre 2 kat fazlaymış.
Bir çalışmaya göre kötü niyetli bir kullanıcı bir şirketteki kullanıcılara zararlı içerik olan bir e-posta gönderdiğinde, 100 kişiden 6'sının gelen e-postadaki ekli dosyaları açtığı belirtlenmiş. Bu kadar çok Bot olmasının, zararlı uygulamaların bu kadar yaygın olmasının ve her geçen gün daha fazla şirketin sunucu ve bilgisayarlarının fidye isteyen korsanlar tarafından ele geçirilmesine şaşmamalı.
Etkinlik sırasında konuşmacılardan birisi, büyük bir şirketin CEO'sunun kendisine anlattığı yaşanmış bir olaydan bahsetti. O büyük şirkette çalışan bir mühendisin gelen ekli bir e-postayı açması neticesinde sunucu, fidye isteyen bir yazılımca kitlenmiş. Çok büyük bir fidye karşılığı kilidi açmayı başarmışlar. Fakat aynı kişi o fidye yazılımının nasıl çalıştığını merak etmiş ve tekrar çalıştırınca aynı fidyeyi yine ödemek zorunda kalmışlar. Konuşmacı bunu anlatırken dinlemeliydiniz, çok güldük.
Yukarıda bahsettiğim gibi doğrudan bize yansımayan başka birçok çeşit ihlal var. Firmaların bu ihlalleri keşfetmesi ortalama 200 gün sürüyormuş. Tabii 200 güne kadar olan oluyor. Yani veritabanınıza sızıldıysa oradaki veriler sızdırılabiliyor veya değiştirilebiliyor veya aklınıza ne gelirse artık, çünkü bu noktada tamamen korsanın insafına kalıyorsunuz.
Veritabanı bazında güvenlik sadece Login oluşturmak/silmek, Ali ve Ayşe'yi X rolünün üyesi yapmak veya yapmamakla sağlanmıyor arkadaşlar. Bu konuda çok daha etraflıca düşünmeniz gerekiyor. Artık her zamankinden çok daha fazla sorumluluğumuz var. Kötü niyetli kişiler kadar çeşitli ve hızlı çözüm geliştiremediğiniz noktada, geri kalıyorsunuz ve hem kendinizi hem de verilerinizi tehlikeye atıyorsunuz. Aman dikkat!
Hayırlı işler,
Ekrem Önsoy
11 Aralık 2016 Pazar
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
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
6 Aralık 2016 Salı
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
Kaydol:
Kayıtlar (Atom)