Hangi Bug’lar Offfff Kapsamına Girer? VMware KB2136854 – CBT

03.12.2015 | 23:37 VMWare 0 Yorum

Yürüttüğümüz projelerden birinde NetScaler’lar ile balance yapıp Palo Alto’lar ile koruduğumuz Cisco UCS Blade’ler üzerine ESXi Cluster, vCenter, vCloud Director, vRealize Log Insight, Horizon gibi çeşitli VMware çözümleri konumlandırıyoruz. Bu vesileyle son dönemde VMware KB’lerini çok daha yakından takip ediyorum. Yine öyle bir gün ve ben KB okuyorum…

vmware-bug

Incremental Backup Nedir?

En temel ifadeyle bir full backup alındıktan sonraki seferlerde sadece son backup anından itibaren değişen verilerin yedeklenmesi prensibine dayanan bir yedekleme yöntemidir. Bu sayede aynı verilerin tekrar tekrar yedeklenmesinin önüne geçilirken ağ kapasitesi daha az yedekleme verisi tarafından işgal edilir, yedekleme alanı ve ilişkili diğer kaynaklar daha verimli kullanılmış olur. Ayrıca bir incremental backup process, full backup process’e göre çok daha kısa sürede tamamlanır, yani hızlıdır.

100GB’lık bir VM’i günde 1 kez yedeklemek ve 7 gün geriye dönük saklamak istediğinizi düşünelim.

Eğer her seferinde full backup alırsanız kabaca;

  • Dezavantaj: 7 x 100GB = 700GB yedekleme alanına ihtiyacınız olur.
  • Dezavantaj: Her bir full yedekleme görevi -incremental’a göre- çok daha uzun sürer.
  • Avantaj: Her bir full yedekleme anı, kendinden önceki veya sonraki yedekleme anlarından bağımsız olarak tek başına geri dönülebilir.

Eğer full backup + incremental backup’lar alırsanız kabaca;

  • Avantaj: 1 x 100GB (full) + 6 x ~5GB (incremental/temsili) = 130GB yedekleme alanına ihtiyacınız olur. Bu da yedekleme alanı kapasitesinin daha verimli kullanılması demek.
  • Avantaj: Incremental backup görevi full backup’a göre çok daha kısa sürer çünkü transfer edilecek değişen (incremental) veri boyutu daima full veri boyutuna göre daha düşüktür.
  • Dezavantaj: Her bir  incremental yedekleme anı kendinden önceki incremental anlarına ve ayrıca full backup anına bağımlıdır. Eğer bu zincirdeki herhangi bir anda sorun yaşanırsa (inconsistency veya corruption gibi) sorun yaşanan an ve sonrasını kaybedersiniz.

O zaman bir backup software‘in incremental backup alabilmesi için bilmesi gereken en temel şey nedir? Tabii ki de son backup anından sonra gerçekleşen değişikliklerdir

CBT – Changed Block Tracking Nedir?

CBT, VM’ler için fiziksel disk üzerinde değişen blokları (sectors) hypervisor seviyesinde takip eden ve bu değişiklikleri API’lar vasıtasıyla incremental backup almak isteyen uygulamalarının bilgisine sunan bir VMware özelliğidir. VMware’ın yerleşik yedekleme çözümü Data Recovery’nin yanı sıra Veeam gibi, Symantec gibi üçüncü taraf backup software üreticileri de incremental backup alırken değişen veriyi anlamak için CBT bilgisini kullanırlar.

Örneğin bir backup software bir VM için incremental backup almak istediğinde vSphere API’ları vasıtasıyla ilgili VM için -son yedek anından itibaren- fiziksel disk üzerinde gerçekleşen değişikliklerin bir listesini ister. Bu talebe istinaden, hypervisor tarafından takip edilen CBT verisi backup software’e iletilir ve backup software fiziksel disk üzerinden sadece ilgili sector’leri okuyarak kopyalar ve bir recovery point olarak depolar.

CBT Enabled ESXi 6.0 VM’lerde Yaşanan Yedekleme Sorunu

KB2136854‘de zaten açıklandığı için detaylara girmeyeceğim ama özetle sorun şu: Running durumdaki VM’leri incremental backup gibi CBT‘den beslenen bir yöntemle yedeklediğinizde içerik inconsistent (tutarsız) durumda oluşuyor ve bundan haberiniz olmuyor :) Yani bir diğer ifadeyle incremental backup almak isteyen software, CBT bilgisini vSphere API’dan QueryDiskChangedAreas() istediğinde, hypervisor tarafından tutulan değişen blok bilgisi backup software’e hatalı olarak iletiliyor ve backup software tutarlı bir yedek anı oluşturamıyor. Düşünsene yedek içeriği daha hypervisor’den çıkarken inconsistent durumda…

Sonra?

Sonrası patch.

Sonra?

Daha sonrası kimine göre “her yazılımda hata olur” kimine göre “hemen patch’lediler” kimine göre ise “bu seviye bir hataya sebep olan geliştirme takımı harakiri yapmalı”

Ben harakiri diyorum. Gelin anlatayım.

***

Öncelikle onlarca mühendisin çalıştığı VMware gibi bir teknoloji şirketinin geliştirdiği yazılımda bu derece kritik öneme sahip bir feature’ın, bu kadar net ve etkisi tartışılmaz seviyede ciddi bir bug ile release olması (veya önceki bir patch ile bu hale gelmesi) nereden tutsan elinde kalır. Bu durum bile tek başına konunun ehemmiyetini anlatmak için yeterli. Diğerleri işin tuzu biberi.

***

Sorun X anında Y koşullarında yaşanıyor olsa kısmen anlarım; sınırlı senaryoda etki eden bir bug deriz, her yazılımda olabiliyor deriz, geçeriz. Ama yapılan hata tüm incremental backup işlemlerine etki etme potansiyeline sahipse ve üretici dahi hangi senaryoların etkilendiğini hangilerinin etkilenmediğini net bir şekilde ortaya koyamıyorsa orada durmak lazım. En tehlikelisi de ne biliyor musun? Çalışıyor gibi görünüyor ve “sorunsuz yedek aldım” diyor ama en lazım olan anda bir bakıyorsun yedekler inconsistent durumda. Bunun yol açacağı sorunları hayal edebiliyor musun?

***

Benim gördüğüm bu hatanın gün yüzüne çıktığı ilk tarih 12 Kasım. VMware’ın patch yayınladığı tarih ise 25 Kasım. Arada en az 14 gün var. 14 gün yahu, on dört gün, XIV koca gün ki muhtemelen öncesi de var. Bak o beğenmediğiniz Microsoft bu gibi durumlarda 24 saat geçmeden patch yayınlıyor. En basit örneği daha geçen gün Outlook/PST’ler için yaşandı. Bun gibi 10’larcasını gösterebilirim.

***

Bu soruna istinaden 12 Kasım’da yayınlanan KB2136854‘de 14 gün boyunca herhangi bir fix ya da çözüm yer almadı. Peki ne yer aldı? Evlere şenlik Workaround’lar…

  1. ESXi Host’ları 6.0’dan 5.5’e downgrade edin. Olur :) Sen binlerce dolar danışmanlık ücreti öde 30 günde 6.0 projesi yap, sonra 2 günde o host’ları 5.5’e downgrade et. Ya hiç akıl karı mı allah aşkına? Senin elinde 2 host varsa eminim yaparsın da bende var 20 host / 500 vm, nasıl olacak o iş? Bunu bir workaround kabul edip uygulayanın aklından şüphe ederim.
  2. Incremental backup almadan önce VM’i shutdown edin. Olur :) SLA yüzünden ayda 60sn downtime tahammülü olan sunucuyu sırf sen consistent backup alamıyorsun diye her gece kapatacağım öyle mi? Orayı yıkarlar.
  3. Incremental yerine full backup alın. Olur :) Her gece incremental yedeklenen ve politika gereği en az 15 gün geriye dönük saklanan 10’larca VM’i bir anda full yedekleyeceğiz ha? VMware göndersin o zaman EMC Storage kabinetini koyalım bizim datacenter’a.

Problem süresince çözüm beklerken ya bu seçeneklerden birisini uygulayacaktın ya da incremental backup almayacaktın. Olay bu kadar net.

***

Yukarıdaki workaround’ların uygulanabilirliği önündeki engeller bir tarafa, ayrıca konudan da haberdar olmanız gerekiyor. Yani ortada böyle bir sorun var ama eğer haberdar değilseniz sıkıntı büyük: 14 gün boyunca yedeklerin sorunsuz alındığını zannediyorsun, ne backup software’de ne de virtualization platform’da herhangi bir hata/uyarı yok, ama es kaza o yedeklerden birisine ihtiyacın olsa ve dönmek istesen elindeki 2 haftalık yedek ÇÖP.

***

14 gün sonra fix çıkıyor. Hadi konudan da haberin var ve hemen geçtin diyelim. Bitti mi? Hayır çünkü fix -haliyle- geçmişte alınan inconsistent backup’ları düzeltmiyor. Sadece bundan sonraki full + incremental backup’ların consistent olmasını sağlıyor. Yani o geriye dönük en az 14 günlük tüm incremental backup içeriği ÇÖP. Önce onları bir güzel sileceksin, sonra bir güzel en baştan full backup alacaksın, ancak o zaman üzerine incremental ve consistent devam edebilirsin. Bu sırada eğer 14 gün geriye doğru bir VM backup’a ihtiyaç olursa durumu nasıl açıklarsın bilmiyorum.

Ha eğer “fix geçtim” rehavetine kapılıp eski yedekleri silmeden incremental devam edersen ilk full backup’a kadar incosistent durum da seninle birlikte devam eder :) Eminim bunu da yaşayanlar olacak çünkü acaba kaç kişi yüklemeden önce o fix’in hangi sorunu düzelttiğine ve düzeltme sonrasında uygulanması gereken post-process’ler olup olmadığına bakıyor? Valla ben 4 kişi tanıyorum, 2’si zaten benimle çalışıyor :)

***

VMware KB2136854‘ü sürekli update ediyor. Bir açıdan bakıldığında bu gayet normal ve hatta iyi bir şey; taze bilgiler ekleniyor. Ama buradan konuyu çok dağınık ve özensiz takip ettiği sonucu da çıkıyor çünkü en basitinden dün Important considerations maddeleri eklenmiş ve demişler ki eğer sanal diskler Eager Zeroed thick ise fix üzerine full VM backup yeterli, diğer sanal disk türleri için (ki bu sınıf çoğunlukta) fix + full CBT reset gerekiyor. Resmen adamlar meseleyi daha yeni keşfedebilmiş. KB yayınlanalı 20 günden fazla, Fix çıkalı neredeyse 10 gün olmuş, insanlar telaşla ilk önerileri dikkate alıp backup’ları silmiş bir şeyler yapmış, bu şu saate eklenecek bilgi mi bu yahu? Bu gibi bilgilerin çoktan KB’de yer alması gerekiyordu.

***

KB’nin cause bölümünde diyor ki incremental backup almak isteyen bir backup software QueryDiskChangedAreas() ile çağrı yaptığında vSphere API’dan dönen değişen blok bilgisi hatalı olabilir. Yani bu şu demek: “Hangi incremental backup’ların inconsistent durumda olduğunu bilemiyoruz, herhangi bir incremental backup -ve tamamı bile- inconsistent durumda olabilir.” Çünkü problem süresince hatasız çalışan hiçbir incremental backup senaryosundan bahsedilememiş.

***

Backup software’lerin yaşanan durum karşısındaki çaresizliği de ayrı bir mesele. Düşünsene incremental backup içeriği daha hypervisor’den inconsistent durumda çıkıyor ve ne virtualization platform’un ne de backup software’ın durumdan haberi dahi olmuyor. Valla tüylerim diken diken oldu… Ama görüntüde her şey yeşil :) (tüyler hariç)

***

Daha yeni (dün) yayınlanan aşağıdaki KB’ler çoktan yayınlanmış olmalıydı.

***

İşte bu gibi bug’lar tam olarak offfff kapsamına girer ve “her yazılımda bug oluyor” argümanıyla asla savunulamaz. Diğeri polyannacılık oluyor zira.

Yazı Etiketleri: , , ,

Sayfa Başı ▲

Yorum Ekle