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

Devam eden projelerimizden 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 KB okuyoruz…

Incremental Backup Nedir?

En genel 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ğ ve disk kapasiteleri daha az yedekleme verisi tarafından işgal edilir ve 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. Örneğin 100GB’lık bir VM’i günde 1 kez yedeklemek ve 7 gün süreyle geriye dönük muhafaza etmek 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 veri boyutu çoğu zaman 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 çeşitli 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() fonksiyonuyla istediğinde, hypervisor tarafında tutulan değişen blok bilgisi backup software’e hatalı olarak iletiliyor ve bundan haberi olmayan backup software tutarlı bir yedek anı oluşturamıyor çünkü yedek içeriği daha hypervisor’den çıkarken inconsistent durumda… Sonra? Sonrası patch. Daha 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ı”… Hepsine katılıyorum ama ben daha çok harakiri diyenlerdenim. Gelin anlatayım.

*  *  *

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 ve 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 musunuz? Ç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, ondört gün, XIV koca gün ki muhtemelen öncesi de var. Bak o beğenmediğimiz 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ı var.

*  *  *

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… Problem süresince çözüm beklerken ya bu seçeneklerden birisini uygulayacaktın ya da incremental backup almayacaktın.

1. ESXi Host’ları 6.0’dan 5.5’e downgrade edin. Tabii ne demek :) 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 kabini koyalım bizim datacenter’a.

*  *  *

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?

*  *  *

VMware KB2136854‘ü sürekli update ediyor. Bu 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ı ise 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() fonksiyonu 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 belki de tamamı- 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…

*  *  *

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

• Changed Block Tracking (CBT) on virtual machines (1020128)
• Resetting Changed Block Tracking for VMware vSphere virtual machines (2139574)
• Enabling or disabling Changed Block Tracking (CBT) on virtual machines (1031873)
• Backing up a Changed Block Tracking enabled virtual machine in ESXi 6.0.x returns incorrect changed sectors (2136854)
• Consolidating virtual machine snapshots fails with the error: Change tracking target file already exists (2135468)

*  *  *

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