Burak Sefa Alpsoy

IBM Ailesine dönüşüm en çok ilgi gören yazılarımdan biri olan HyperSwap ve replikasyon konusundaki güncelleme olan Storage Virtualize 8.7.1 ile denk geldi. Bu yazıyla bunu kutlamak istedim.

Görsel-1’de görebileceğiniz üzere, geçmişten bildiğimiz senkron,asenkron replikasyon ve Hyperswap servisleri yerine, politika tabanlı yeni servisler adresleniyor.

Görsel-1

Politika tabanlı replikasyon, volume gruplarının yapılandırılmasını, yönetimini ve izlenmesini büyük ölçüde kolaylaştırıyor. Peki, neden politikaları kullanıyoruz? 3 adımda toparlayalım:

Tutarlılık: Her bir volume’un doğru şekilde yapılandırılması, sistemin güvenilirliği açısından kritiktir. Bu noktada, politikalar devreye girer ve replikasyonun nasıl yapılandırılması gerektiğini net bir şekilde tanımlar. Sistem, bu politikaları uygulayarak tutarlılığı garanti altına alır.

Basitlik: Remote provisioning işlemlerinin tümü sistem tarafından yönetildiğinde, sistem yöneticileri için büyük bir rahatlık sağlar. İş yükünün azalması bir yana, hata yapma riskinin ortadan kalkmasıyla yönetim çok daha kolay bir hale gelir. Günlük operasyonlar, tek bir ekrandan kontrol edilebildiğinde işlerin ne kadar hızlandığını görmek gerçekten etkileyici.

Otomasyon: Günümüz dünyasında manuel müdahaleler ne kadar az olursa, sistem o kadar verimli olur. Replikasyonun mevcut koşullara kendiliğinden uyum sağlaması, performans sorunlarına neden olmadan sürekli olarak optimize edilmesi demektir. RPO’ların aşıldığı durumlarda ise sistemin sizi raporlarla ve uyarılarla bilgilendirmesi, kontrolü tamamen elden bırakmadan süreci otomatikleştirmenin en güzel örneği.

Politika bazlı replikasyon tasarımında bir Volume Grubu içindeki tüm volume’lerin aynı failure domain içinde olduğundan emin olmak için: ( Görsel-2)

• Tüm volume’ler aynı I/O grubunda yer almalıdır.
• Replikasyon, yalnızca I/O grubu partneriyle iletişim kurar, bu da en yüksek performansı sağlar.

Görsel-2

Esnek replikasyon kuralları oluşturabilirsiniz, yani Volume Grup 1 için RPO 3 saat olacak şekilde, Volume Grup 2 için yarım saatlik bir RPO ile kural oluşturabilirsiniz. Görsel 2’de buna yönelik tasarım örneğini görebilirsiniz. Tüm volume gruplarının aynı I/O grubunda olması gerekliliği, geçmişe göre bir farklılık ve uygulamada dikkat edilmesi gereken noktalardan biri.

Görsel 3’te replikasyon olmadığında, geleneksel global mirror ve yeni politika bazlı modelin performans karşılaştırmalarını görebilirsiniz.

Görsel-3

Politika bazlı yüksek erişilebilirlik (High Availability)

Host erişimi:

• PB-HA ( Politika bazlı yüksek erişebilirlik) , host erişimini ve kopya yönünü tanımlamak için Partitions kullanır.
• Host, volume’ler ve volume grupları aynı partition’a atanmalıdır.

Host Multipath yazılımı:

• Veri erişimini, konum ayarına bağlı olarak yönetmekle sorumludur.
  1. Konum ayarı olmayan host:
     Host, her zaman replikasyon kaynak volume’lerine giden yolları kullanır.
     Bu partition için aktif yönetim sistemi olan depolama her zaman replikasyon kaynağıdır.
  2. Konum ayarı olan host:
     Host, veri okuma ve yazma işlemleri için aynı konumdaki volume’lere giden yolları kullanır.
     Veri akışı optimize edilir çünkü veri yalnızca bir kez uzun mesafe bağlantısını kullanır.

Görsel-4

HyperSwap’tan PB Yüksek Erişilebilirliğe (PB High Availability) Geçiş (Görsel 5-6):

1. HyperSwap volume’lerini, tek bir I/O grubunda önbelleğe alınmış normal volume’lere dönüştürün.
2. Boş I/O grubundaki düğümleri kümeden çıkarın.
3. Kontrol ünitesini yeni bir bağımsız sistem olarak yeniden kurun. Yeni sistemi kontrol ünitesi ile yapılandırın, temel kurulumu gerçekleştirin ve havuz ve depolamayı yapılandırın.

Görsel-5

• Orijinal sistemde GUI sürecini kullanarak mevcut volume’lerle yeni bir partition oluşturun.

5. HA ekleyin ve tüm verileri yeni partner sisteme aktarın.

Görsel-6

Bir sonraki yazıda, FlashSystem üzerinde bugün tasarım olarak konuştuğumuz yüksek erişilebilirlik çözümünü nasıl kurguladığımızı ele alacağım. Spesifik sorularınız olursa, mutlaka o yazı içerisinde cevaplamaya çalışacağım.