Bugünkü yazımda sizlere Hitachi’nin “ Hitachi Storage Virtualization Operating System” (SVOS)’ ile sağladığı “global-active-device” özelliğinden bahsedeceğim. Bu özellik sayesinde dağıtık sistem yapınızı ve bu yapının operasyonunu kolaylaştırabilirsiniz. GAD sayesinde, RTO (Recovery Time Objective) ve RPO (Recovery Point Objective) değerlerinizi sıfıra indirgeyebilirsiniz. Şekil 1.1.’de GAD’ın yapısal olarak nasıl çalıştığını gösteren görseli görebilirsiniz.
Şekil 1. Global-Active-Device Mimarisi
GAD, aynı verinin aynı anda okuma/yazma kopyalarının iki farklı lokasyonda olmasını destekler. Aktif-Aktif bir yapı olarak çalışır. Yani iki VSP (Hitachi Virtual Storage Platform) sistem arasında “volume” ler “mirror” yapıda çalışmaktadır. Her iki taraftaki VSP’ler yazma/okuma isteklerini kabul eder. IO, sürekli bir şekilde güncellenmektedir. Herhangi bir lokasyonda “disk controller” unitesi hata alırsa, diğer lokasyondaki “disk controller”, zaten aktif olarak devrede bulunduğu için okuma/yazma isteklerini kabul eder. GAD, her iki lokasyonda güncel “volume” ün daima güncel ve kullanılabilir olduğunu garanti eder. Yani her iki lokasyonda uygulama iş yükü daima mevcuttur. GAD, elbette bu özelliği sunarken, tam bir veri tutarlılığı ve veri koruması sağlar.
Ana merkezde veriye ulaşımı engelleyen herhangi bir kritik durumda, DR lokasyondan uygulamaların başlatılması gerektiğinde kullanılan teknolojilerden ötürü manüel olarak geçiş yapılması gerekebilir. GAD, sağladığı “stretched clusters” yapısıyla geçişlerin otomatik olarak yapılmasını sağlamaktadır. Bu sayede uygulamalar, lokal veya metro uzaklığındaki lokasyondaki ikinci kopyaya anında ulaşabilmekte ve uygulamanın manüel “fail-over” yapılmasına ihtiyaç duyulmamaktadır.
GAD’ın “workload mobility” sağladığınıda söylemek mümkün. Çok yoğun saatlerde sistem yöneticisi yükü dengelemek için uygulamayı ikinci bir sunucuya aktarmak isteyebilir. GAD’ın anlık “mirror” özelliği verinin ikinci lokasyonda anlık varlığını sağladığı için uygulamada herhangi bir kesintiye gerek kalmayacaktır. Bu yöntem, sunucunun geçici olarak bakım için kapatılması gerektiği durumlarda da çok kullanışlı olacaktır.
GAD, veri migrasyonu içinde kullanılabilir. Örneğin VSP’de çok kritik bir uygulama çalışıyor olabilir. Ortama ikinci bir VSP alındığını varsayalım. Data migrasyonu, GAD sayesinde hiçbir kesintiye neden olmaksızın ikinci VSP sisteme yapılabilecektir.
Özet olarak, kolay yönetilebilir ve kolay yapılandırılabilen iş sürekliliğine ihtiyaç duyan firmalar için, GAD, kesintisiz operasyon sağladığı gibi sistemler ve veri merkezleri arasında “workload mobility” i de sağlamaktadır. Yani sağladığı basite indirgenmiş ve otomatikleştirilmiş operasyonun yanı sıra, esneklik, ölçeklenebilirlik, güvenilirlik sağlayan GAD, misyon kritik veri ve uygulamalar içinde kesintiyi ortadan kaldırmaktadır.
Yazının sonunda eklediğim kaynaklarda, Oracle RAC 11gR2 için Hitachi VSP G1000’nin kullanıldığı detaylı teknik makaleyi inceleyebilirsiniz. Ben bu yazıda özet olarak ilgili çalışmadan bahsedeceğim. Bu çalışma, VSP G1000 için SVOS global-active device özelliğinin Oracle veritabanı yapısı için farklı lokasyonlarda konumlandırılan veri merkezlerinde nasıl iş sürekliliği ve “high-availability” sağladığını anlatmaktadır. Mimari, birbirinden 100Km uzakta olan iki tane VSP G1000’nin senkron replikasyon modelini kullanmaktadır. Oracle RAC yapısı 4 “node” dan oluşmaktadır. Lokal VSP G1000’de bir problem olduğunda, Oracle istemciler herhangi bir kesinti almadan uzak lokasyondaki G1000’e bağlanabilmektedir. Şekil 2’de lokal ve uzak lokasyonda her birinde 2 quest olan sunucuları, her bir lokasyondaki G1000 sistemleri görebilirsiniz.
Çözümde Oracle ASM Disk Grup kullanıldı. ASM disk grup için VSP G1000’nin nasıl yapılandırıldığını Şekil 3’te görebilirsiniz.
“Active-Active” konfigürasyonda, “non-preffered path” opsiyonu, kullanılabilir yapılırsa, lokal sunucudaki IO lokal VSP 1000 depolama birimine gidecektir; uzak sunucudan yapılan IO’da VSP 1000 uzak depolama birimine gidecektir. Yani, lokal depolama birimi hata almadığı müddetçe, lokal sunucular uzak depolama birimine yazmayacaktır. Aynı kural, uzak sunucudan yapılan IO’lar içinde geçerlidir. Yani uzak sunucudan yapılan IO’lar, uzak depolama biriminde bir problem olmadıkça lokal VSP 1000’e yazılmayacaktır.
Lokal VSP G1000’de bir problem olduğunda, IO uzak lokasyondaki VSP G1000’e yönlendiği için, 4-node’lu Oracle RAC aktif ve fonksiyonel olacaktır.
Şekil 2’de sözü geçen ANUE, lokal ve uzak lokasyonun birbirinden 0 KM, 50KM, 100KM uzakta olma durumunu simüle etmek için kullanılmıştır. İlgili çalışma aradaki mesafeye göre saniyedeki ortalama işlem sayısınıda analiz etmiş durumdadır.
Şekil 2. Oracle RAC 11gR2 ile Kullanılan GAD Mimarisi
Özet olarak, GAD sayesinde, misyon-kritik uygulamalarınızı farklı lokasyonlarda ihtiyaç duyulduğunda 0 RTO/RPO değerleriyle manual “recovery” işlemlerine gerek kalmadan çalıştırabilirsiniz.
Asiye Yiğit 22 Şubat 2017
Kaynakça:
https://www.hds.com/en-us/pdf/datasheet/hitachi-datasheet-global-active-device.pdf
Leave A Comment