Dell, VMware Site Recovery Manager ile birlikte kullanılan SRDF Storage Replication Adapter (SRA) için yeni bir yama yayımladı 10.3.0.2.
Sürüm numarasındaki .2 ifadesi ilk bakışta kafa karıştırabilir çünkü ortada bir 10.3.0.1 yok. Bunun nedeni tamamen iç süreçlerle ilgilidir geliştirme ekibi dahili derlemeler (internal builds) nedeniyle sürümü bir kez revize etmek zorunda kaldığından kamuya açık ilk yama doğrudan .2 olarak çıktı. Yani bu bir atlama ya da eksik bir paket değil numaralandırma bilinçli olarak bu şekilde ilerledi.
Yamayı Dell destek sayfasındaki sürücü bölümünden, “SRDF Adapter for VMware Site Recovery Manager” başlığı altından indirebilirsiniz.
SRDF SRA Tam Olarak Ne Yapıyor?
Konuya hâkim olmayanlar için kısa bir hatırlatma yararlı olacaktır.
SRDF teknolojisi Dell’in kurumsal depolama dizilerinde (PowerMax / VMAX ailesi) çalışan diziden – diziye veri replikasyon teknolojisidir.
SRA (Storage Replication Adapter) ise bu replikasyonu VMware’in felaket kurtarma orkestrasyon katmanına bağlayan ara yazılımdır.
VMware Site Recovery Manager son dönemde VMware Live Site Recovery (LSR) adıyla anılıyor bir felaket kurtarma senaryosunda hangi makinelerin, hangi sırayla, nereye taşınacağını yönetir ancak depolama seviyesindeki replikasyon yönünü çevirmek R1/R2 rollerini takas etmek gibi diziye özgü işlemleri SRA üzerinden gerçekleştirir.
Dolayısıyla SRA’daki en küçük bir mantık hatası bile failover anında doğrudan iş sürekliliğini etkileyebilir.
Bu yama daha önce ayrı birer hot fix olarak sunulmuş olan iki hatayı kalıcı biçimde içeriyor. Her iki düzeltme de geliştirici tarafından “köşe senaryo” (corner case) olarak nitelendiriliyor; yani her ortamda değil, belirli ve görece nadir konfigürasyonlarda ortaya çıkıyorlar. Yine de etkileri ciddi olduğu için yamanın varlığı önemli.
Birinci Düzeltme: 2 Saha SRDF/Metro’da Bias Sorunu
İlk ve geliştiricinin kritik olarak değerlendirdiği düzeltme iki sahalı SRDF/Metro yapılandırmasıyla ilgili. Bu konfigürasyon sahada çok yaygın değil SRDF/Metro kurulumları genellikle üçüncü bir saha içerir ancak hatanın doğrudan failover’ı engellemesi onu önem sırasında yukarı taşıyan asıl etken oldu.
SRDF/Metro’nun çalışma mantığını anlamak sorunu da anlamayı kolaylaştırıyor. SRDF/Metro aktif-aktif senkron bir replikasyon modelidir: R1 ve R2 birimlerinin ikisi de eş zamanlı olarak okuma-yazmaya açıktır ve sunuculara tek bir mantıksal cihaz gibi sunulur.
Böyle bir mimaride en kritik soru şudur bağlantı veya saha kaybı yaşandığında hangi kopya “kazanan” olarak hayatta kalacak? İşte bu kararı belirleyen iki mekanizma vardır bias ve witness.
Her SRDF/Metro çifti bir witness (hakem/tanık) kullanıyor olsa bile mutlaka bir bias sahasına sahiptir.
Bias, witness’ın kendisinin devre dışı kalması ihtimaline karşı bir güvence görevi görür hakem çökerse, varsayılan olarak bias sahasındaki kopya hayatta kalır. SRDF SRA’nın muhatap aldığı saha da işte bu bias sahasıdır.
Sorun şu senaryoda ortaya çıkıyordu. Diyelim ki bias sahanız çöktü ve ortamda bir witness var. Bu durumda witness devreye girer ve daha önce R2 olan kopyanız hayatta kalan yeni R1 bias rolünü üstlenir.
Yani bias artık karşı tarafa geçmiştir. Yamadan önce bias bu şekilde el değiştirmişken SRM/LSR üzerinden bir failover başlatmaya çalıştığınızda, SRA mevcut bias durumunu kontrol etmiyordu. Kontrol etmediği için de bias’ı körlemesine ters yöne tekrar takas etmeye çalışıyor bu da o anki R1’i yeniden R2 konumuna düşürüyordu. Sonuç olarak failover işleminin tam yapması gereken şeyi tersine çevirdiği için işlem başarısız oluyordu.
Yamanın getirdiği düzeltme oldukça doğrudan SRA artık herhangi bir takas işlemi yapmadan önce bias durumunu kontrol ediyor.
Eğer bias zaten karşı tarafa geçmişse SRA gereksiz bir takas başlatmıyor ve böylece failover sağlıklı biçimde tamamlanıyor.
İkinci Düzeltme: Test Failover’da Mevcut Cihaz Çiftleri Sorunu
İkinci düzeltme otomatik ve manuel test failover senaryolarını ilgilendiriyor. Buradaki hata ortamda halihazırda mevcut cihaz çiftleri (existing device pairs) bulunduğunda cihaz yeniden kullanımı (device reuse) “false” olarak ayarlanmış olmasına rağmen SRA’nın test failover işleminde başarısız olmasıydı. Mantıksal olarak device reuse kapalıyken mevcut çiftlerin bu işlemi engellememesi gerekirdi ancak kod bu durumda beklenmedik şekilde takılıyordu.
Bu hatanın nasıl gün yüzüne çıktığı da öğretici. Hatayı tetikleyen müşteri SRM/LSR ile yürüttüğü test failover’lara ek olarak manuel test failover’lar da çalıştırıyordu.
Çoğu kurum bu iki yöntemi bir arada kullanmaz SRM/LSR’niz varsa testlerinizi onun üzerinden yaparsınız yoksa testi manuel olarak gerçekleştirirsiniz.
Bu iki yaklaşımın aynı ortamda birleştirilmesi normalde görünmeyen bu hatanın yüzeye çıkmasına neden oldu. Düzeltme, ilgili kod akışındaki bir kısım mantığın yeniden ele alınmasıyla sağlandı.
Bu Yamayı Uygulamalı mıyım?
Yukarıda açıklandığı gibi her iki düzeltme de köşe senaryolarına yönelik. Dell bu tür yamaları yayımlarken bunları her zaman “önerilen” (recommended) olarak etiketler çünkü düzeltmelerin elde bulunması, bulunmamasına kıyasla her zaman daha güvenlidir. Ancak buradaki ayrım önemli: “önerilen” etiketi, “her ortam için zorunlu” anlamına gelmiyor.
Pratik karar şu şekilde özetlenebilir. Eğer ortamınız iki sahalı SRDF/Metro yapılandırması çalıştırmıyorsa ve SRM/LSR test failover’larınızı manuel testlerle birleştirmiyorsanız, bu iki koşulun hiçbiri sizi etkilemiyor demektir. Bu durumda yamayı uygulamak zorunlu değildir. Üstelik çoğu müşteri için SRA yama süreci kesinti gerektiren (disruptive) bir işlem olduğundan, sizi ilgilendirmeyen düzeltmeler için bu kesintiyi göze almanın bir gereği yoktur.
10.3.0.2 gerçek ve önemli iki sorunu kalıcı olarak çözüyor, ancak bu sorunların her ikisi de belirli konfigürasyonlara özgü. Kendi ortamınızdaki SRDF/Metro ve test failover pratiklerinizi gözden geçirin; tanımlanan koşullardan biri sizde varsa yamayı planlamak yerinde olur, yoksa mevcut sürümünüzle devam etmenizde bir sakınca yoktur.
