Burak Sefa Alpsoy

hayal edenden hallice

recent posts

about

  • Yapay Zeka Yatırımlarında, Çoğunlukla Göz Ardı Edilen Depolama Sorunları

    Yapay Zeka Yatırımlarında, Çoğunlukla Göz Ardı Edilen Depolama Sorunları

    Yapay zekanın (AI) yaygınlaşması, geleneksel iş modellerinde bir değişim gerektirdiğini çeşitli makalelerde, videolarda ve tüm konu uzmanlarının yazılarında görüyoruz. Şirketler, müşteri deneyimlerini zenginleştirmek, operasyonel verimliliği artırmak ve yenilikçiliği desteklemek için yapay zekaya giderek daha fazla yöneliyor.

    Yapay zekanın sunduğu avantajlardan yararlanmak için gelişmiş depolama mimarilerinin sunulması kritik bir rol oynuyor. Bu kapsamda, AI iş yüklerinin taleplerini karşılayacak, özellikle Grafik İşlem Birimi (GPU) kullanımını en üst düzeye çıkaracak depolama tasarımları gerekiyor, bu yazıda kısaca bunun neden gerektiğine ve dikkat edilmesi gereken noktalara değineceğim, sizlerin yorum ve fikirlerinizi de görmekten mutlu olurum.

    Yapay Zeka Sistemlerinde Temel Amaç: Tam GPU Kullanımı

    Yapay zeka iş yükleri; işlemci ve bellek sınırlarını zorladıkça, geleneksel depolama sistemleri yetersiz kalıyor. Modern bir AI veri merkezinde temel hedef, sadece yüksek performans veya geniş kapasite sağlamak değil, GPU’ların tam kapasiteyle çalışmasını desteklemek.

    Ancak, GPU’lar işlem gücü eksikliğinden değil, depolama sistemlerinin veri akış hızına ayak uyduramamasından dolayı atıl durumda kalıyor. Bu durum, GPU gibi altyapı yatırımlarının tam kapasite kullanılmaması ve modellerin geliştirilme, fine tuning gibi işlemlerin süresinin uzamasına neden oluyor.

    Yapay zeka konusundaki patlama, GPU’lara yönelik inanılmaz bir talep yarattı. GPU’lar, AI’ı uygulanabilir kılmak için gerekli. Talep, maliyet ve temindeki kısıtlar, GPU’ları en değerli AI altyapı varlığı haline getirdi ve şirketlerin sahip oldukları GPU’ların kullanımını en üst düzeye çıkarmasını gerektiriyor.

    Peki, bu kadar maliyetli ve temini zor olan bu GPU’ların potansiyelini tam olarak kullanabiliyor muyuz?

    I/O Darboğazları ve AI Yatırım Getirisine Etkisi

    Depolama darboğazı, 8 şeritli bir otoyolun aniden tek şeritli bir köy yoluna dönüşmesi gibidir. Ne kadar güçlü arabalarınız (GPU’larınız) olursa olsun, hepsi o tek şeritte sıkışıp kalır.

    GPT-3 veya 3D U-Net gibi modern AI modellerinin GPU grupları üzerinde eğitilmesi, büyük miktarda verinin işlemci birimlere kesintisiz olarak sağlanmasını gerektirir.

    Derin öğrenme iş yükleri ise modele, veri formatına, kullanılan framework’e ve erişim protokolüne bağlı olarak oldukça değişken I/O performansı sergiler. Eğer depolama sisteminin kapasitesi, gecikme süresi veya eş zamanlı işlem kapasitesi bu değişken ihtiyaçları karşılayamazsa, maliyetli GPU’lar kapasitesine oranla atıl kalarak yatırımın geri dönüşünü olumsuz etkiler ve model geliştirme süresini uzatır.

    AI Odaklı Depolama İçin Temel Tasarım İlkeleri

    GPU verimliliğini arttırmak ve AI işlemci birimlerini desteklemek için, ağ ve depolama performansını dengelemek gerekir.

    • Katmanlı Depolama Mimarileri: Hız ve maliyet arasında bir denge kurmak amacıyla katmanlı depolama mimarileri kullanılır:
      • NVMe (Katman 0): Aktif olarak kullanılan sıcak  verilerin yüksek hızda alınması için.
      • SSD Depolama (Katman 1): Aktif meta veriler, log dosyaları vb. için.
      • Nesne veya Yeterli Performans Sunan HDD-Teyp Depolama (Katman 2): Büyük model çıktıları, checkpoint arşivleri ve daha az sıklıkla erişilen soğuk veri kümeleri için.
    • Hibrit Erişim Protokolleri: Depolama performansı, kullanılan protokole göre önemli ölçüde farklılık gösterir. Bu nedenle, aşağıdaki gibi hibrit bir yaklaşım benimsenir:
      • Küçük boyutlu ve rastgele okuma gerektiren iş yüklerinde (örneğin, görüntü sınıflandırma) eğitim veri setlerine POSIX uyumlu erişim için NFS (Network File System) kullanılır. NFS, tek bir sunucuda birden fazla model örneği eğitildiğinde işletim sistemi sayfa önbelleğinden yararlanır.
      • Büyük dosyaların serileştirilmesi için S3 uyumlu nesne depolama kullanılır. S3 protokolünde işletim sistemi düzeyinde bir önbellekleme mekanizmasının olmaması, NFS’ye kıyasla depolama sistemi üzerindeki baskıyı artırır. Bu durum göz önünde bulundurularak ön yükleme ve arabelleğe alma stratejileri buna göre ayarlanır.

    Sizin altyapınızda NFS mi yoksa S3 mü daha iyi performans gösteriyor? Deneyimleriniz neler?

    • Akıllı Kontrol Noktası (Checkpointing) Sistemleri:

    Checkpointing uzun bir yolculukta düzenli olarak mola verip haritada nerede olduğunuzu işaretlemeye benzetebiliriz. Eğer bu işaretleme çok yavaş olursa, yolculuk bir türlü bitmez.

    Büyük AI modellerinde kontrol noktası dosyalarının boyutu 2 Terabayt’ı aşabilir. Bu dosyaların verimli bir şekilde kaydedilmesi ve geri yüklenmesi için şu stratejiler uygulanır:

    • Kontrol noktası yazma işlemleri paralelleştirilir ve SSD stripe sınırlarıyla hizalanır.
    • Yazma bant genişliği, parametre başına 14 bayt (ağırlıklar + iyileştirici durumu) gibi bir yöntemle modellenir.
    • Kontrol noktası alma sıklığı ve dosya düzenleri, çalışma zamanı üzerindeki etkinin %5’in altında tutulması hedeflenerek ayarlanır. Kontrol noktaları, yalnızca hata toleransı için değil, aynı zamanda çoklu model eğitiminin kurtarılması için de kritik öneme sahiptir. Tüm GPU’lara kontrol noktası dosyalarının 5 dakikanın altında bir sürede aktarılabildiği, paralel ve çoklu geri yükleme yeteneğine sahip sistemler tasarlamak gerekir.

    Kontrol noktaları, bir arıza veya kesintiden sonra eğitime devam etmek için gereken eğitim durumunu periyodik olarak kaydeder. Kontrol noktaları, öğrenilmiş model ağırlıklarını ve iyileştirici durum bilgilerini içerir. Eğitim genellikle kontrol noktası alma sırasında duraklatılır, bu da GPU kullanımını azaltır; bu nedenle işlemin hızla tamamlanması önemlidir.

    AI I/O Desenlerinin Profilini Çıkarma

    DLIO gibi araçlar kullanılarak, I/O performansı framework seviyesinde ölçülür. Bu analizlerden elde edilen bazı önemli kısımlar şunlar:

    • NFS üzerinden yürütülen ResNet50 iş yükleri, 64KB ile 256KB arasında değişen sıralı okuma işlemleri içerir. DLIO, TensorFlow Resnet50 uygulamasını, GPU’ları bir hesaplama süresi gecikmesiyle taklit edecek şekilde değiştirir.
    • Aynı iş yükü S3 üzerinden yürütüldüğünde ise, I/O desenleri 20MB ile 50MB arasında değişen daha büyük nesne okumalarına kayar ve gecikme süresi artar.
    • Paylaşılan düğümlerde eş zamanlı çalışan modeller sıklıkla aynı verileri yeniden okur. NFS kullanıldığında, işletim sistemi sayfa önbelleği depolama üzerindeki baskıyı azaltırken, S3 bu tür bir önbellekleme avantajı sunmaz. Bu farklılıklar, donanım seçimini, önbellekleme politikalarını ve protokol tercihlerini doğrudan etkiler. Eğitim verisi depolama okuma bant genişliği gereksinimleri büyük ölçüde değişir.

    Ölçeklenebilirlik ve Çoklu Kullanım (Multi-Tenancy) İçin Tasarım

    Modern AI yapıları, birden fazla eş zamanlı işi çalıştırır. Bu tür ortamlar için aşağıdaki özelliklere sahip depolama sistemleri oluşturulur:

    • I/O açlığını önlemek için namespace yalıtımı, kotalar ve Hizmet Kalitesi (QoS) özelliklerine sahip paylaşımlı ad alanları.
    • Hem kapasite hem de performans açısından yatay olarak ölçeklenebilen elastik depolama arka uçları (örneğin, RDMA veya NVMe-oF aracılığıyla).
    • Erişim telemetrisine dayanarak sıcak/soğuk katmanlamayı optimize eden politika tabanlı veri yerleştirme motorları. Modern GPU kümeleri binlerce sunucu ve on binlerce GPU içerebilir.

    Performansın Ötesinde: Kurumsal Depolama Gereksinimleri

    Performans eşikleri karşılandıktan sonra, kurumsal düzeydeki diğer gereksinimler ortaya çıkar:

    • Modelin korunması için şifreleme ve erişim kontrolü.
    • MLOps (Makine Öğrenimi Operasyonları) süreçlerinde tekrarlanabilirliği sağlamak için anlık görüntü (snapshot) ve klonlama desteği.
    • Veri saklama zorunluluğu ve verimli arşivleme için yaşam döngüsü yönetişimi (ILM).

    Sonuç: Rekabetçi AI Altyapısının Temeli

    Depolama, AI işlem hattının adeta bir güç düzenleyicisidir. Güçlü GPU’lara ve dağıtık platformlara yatırım yaptıkça, elde edilecek performans ve yatırım getirisi, giderek artan bir şekilde I/O farkındalığına sahip ve iş yüküne göre hizalanmış depolama mimarilerine bağlı olacaktır.

    Kısacası, AI yaşam döngüsü boyunca yüksek performans gösteyen ve ölçeklenebilen akıllı bir depolama stratejisi, rekabetçi AI altyapısının temelini oluşturur.

  • LTO-10 Resmen Duyuruldu! Veri Depolamada Yeni Bir Dönem Başlıyor!

    Sistem altyapıları ve teknoloji dünyası için heyecan verici bir haber: Uzun süredir beklenen LTO-10 tape teknolojisi artık bizimle!

    Veri depolamanın en uygun maliyetli, çevre dostu ve güvenilir çözümü, şimdi çok daha güçlü özelliklerle geliyor.

    Öne Çıkan Detaylar:

    • Devasa Kapasite: Kartuş başına 30 TB doğal (native), 75 TB‘a kadar sıkıştırılmış (2.5:1) kapasite! Bu, LTO-9’a göre %66’lık bir artış anlamına geliyor.
    • Yüksek Hız: 400 MB/s‘ye varan doğal veri aktarım hızı (Full-Height sürücüler için).
    • Modern Arayüzler: 32Gb Fibre Channel (FC) ve 12Gb SAS desteği.
    • Kullanım Kolaylığı: Artık yerinde başlatma (on-site initialization) gereksinimi yok! LTO-10 medyasını kutudan çıktığı gibi kullanabilirsiniz.
    • Gelişmiş Kafa Teknolojisi: Yeni kafa tasarımı, gelecekteki geliştirmelerin önünü açarken, LTO-9’daki medya optimizasyonu ve arşiv ayırma (unthread) ihtiyacını ortadan kaldırıyor.
    • Kuantuma Hazır Güvenlik: Kuantuma dirençli AES/GCM256 donanımsal şifreleme ve post-kuantum kriptografi anahtar değişimine hazır.

    LTO teknolojisi, her 3-4 yılda bir kendini yenileyerek 25 yıldır veri dünyasının temel taşlarından biri olmaya devam ediyor. LTO-10 ile bu gelenek daha da güçlenerek sürecek!

    ⚠️ Önemli Not: LTO-10 sürücüler, kullanılan yeni nesil kafa teknolojisi nedeniyle LTO-9 medyalarını okuyup yazamayacaktır.

    Düşünelim ki LTO kartuşları birer kitap, okuma/yazma kafaları da bu kitapları okuyup üzerine not alabilen özel bir kalem gibi.

    Her yeni LTO serisinde (LTO-7, LTO-8, LTO-9 vb.), bu kalemler genellikle bir önceki neslin kitabını da okuyabilecek şekilde tasarlanırdı. Yani LTO-9 sürücüsü, LTO-8 kartuşunu okuyup yazabiliyordu (ve LTO-7’yi sadece okuyabiliyordu).

    Ancak LTO-10 ile durum biraz değişti. Bunun temel nedeni, tamamen yeni ve çok daha gelişmiş bir okuma/yazma kafası teknolojisine geçilmesi.

    Şöyle detaylandıralım:

    1. Daha Yüksek Veri Yoğunluğu İhtiyacı: LTO-10, LTO-9’a göre kapasitede çok büyük bir sıçrama yapıyor (18 TB’dan 30 TB doğal kapasiteye). Bu kadar fazla veriyi aynı boyuttaki bir teyp şeridine sığdırabilmek için, verilerin üzerine yazıldığı manyetik izlerin çok daha ince ve birbirine çok daha yakın olması gerekiyor. Eski LTO-9 kafası, bu kadar hassas ve yoğun yazılmış izleri doğru bir şekilde okuyup yazacak yetenekte değil.
    2. Yeni Kafa Mimarisi: LTO-10’da kullanılan kafa, sadece daha hassas olmakla kalmıyor, aynı zamanda teyp şeridiyle etkileşim şekli ve veri okuma/yazma prensipleri açısından da farklılıklar içeriyor. Bu, LTO-9’un kullandığı kafa tasarımının artık bu gelişim için bir sınır teşkil ettiği anlamına geliyor. Gelecekteki LTO nesillerinin (LTO-11, LTO-12 vb.) önünü açmak için bu köklü değişim şarttı.
    3. Eski Teknolojinin Kısıtlarından Kurtulmak: LTO-9’da medya optimizasyonu ve arşiv ayırma (unthread) gibi bazı ek işlemler gerekebiliyordu. LTO-10’un yeni kafa ve mekanik tasarımı, bu tür ihtiyaçları ortadan kaldırarak daha akıcı bir kullanım sunuyor. Ancak bu iyileştirmeler, temel çalışma şeklinde değişiklikler getirdiği için eski nesil medyalarla uyumluluğu da etkiliyor.

    Bir benzetme yapacak olursak:

    Elbette mükemmel bir benzetme olmayacak ama şöyle düşünün: Yıllarca kullandığınız bir kasetçalarınız var (LTO-9 sürücüsü). Sonra aniden Blu-ray teknolojisi (LTO-10) çıkıyor. Blu-ray diskler de dairesel ve parlak ama içindeki verinin yazılma ve okunma şekli, kasetlerdeki manyetik şeritten tamamen farklı. Kasetçalarınıza bir Blu-ray disk takıp bir şey çalmasını bekleyemeyiz.

    İşte LTO-10 ve LTO-9 arasındaki durum da buna benziyor. Dışarıdan bakıldığında ikisi de teyp kartuşu olsa da, LTO-10’un veriyi işleme ve depolama biçimi o kadar köklü bir şekilde değişti ki, LTO-9’un kalemi bu yeni kitabı okuyamıyor.

    Bu durum, geriye dönük uyumluluk açısından bir kayıp gibi görünse de, aslında teyp teknolojisinin gelecekte çok daha yüksek kapasitelere ve hızlara ulaşabilmesi için atılmış önemli ve gerekli bir adım. Üreticiler, bu kararı alırken uzun vadeli faydaları ve teknolojinin sınırlarını daha da zorlama potansiyelini göz önünde bulunduruyorlar.

    En Temel Sebep: Baştan Tasarlanan Okuma/Yazma Kafası Teknolojisi

    LTO-10’un LTO-9’a göre kapasiteyi neredeyse iki katına (18 TB’dan 30 TB’a doğal kapasite) çıkarabilmesi ve yüksek hızları koruyabilmesi için, teyp üzerine veri yazan ve okuyan “kafa” dediğimiz parçanın tamamen yeniden tasarlanması gerekti. Şöyle düşünebilirsiniz:

    Sonuç Olarak:

    LTO konsorsiyumu, LTO-10 ile gelecekteki kapasite ve performans hedeflerine ulaşabilmek için radikal bir karar alarak kafa teknolojisinde büyük bir değişiklik yaptı. Bu değişiklik, LTO-9 ile olan geriye dönük uyumluluğun feda edilmesini gerektirdi. Yani, bu bir “eskiyi bırak, daha iyisine odaklan” durumu. Evet, bir önceki nesille uyumsuzluk bazı zorluklar getirebilir, ama bu, teyp teknolojisinin sınırlarını daha da zorlamak ve veri depolamada yeni ufuklar açmak için atılmış stratejik bir adım.

    https://www.ibm.com/products/lto-tape-drive

    📅 Genel Kullanıma Sunulma (GA): 13 Haziran 2025

  • Geçmişten Günümüze: IBM Replikasyon ve Yüksek Erişilebilirlik Çözümleri Serisi-Uygulama

    Öncelikle aşağıdaki görseldeki gibi 2 storage ve sunucuların network üzerinden yüksek erişilebilirliğe uygun bağlantılarının yapıldığından emin olmalıyız,

    İlk adım olarak lokasyon-1 storage üzerinde Görsel-1’deki gibi, Pool sekmesi üzerinden, sol üstteki Create butonuyla, Pool oluşturuyoruz,

    Görsel-1

    Görsel-2’de göreceğiniz gibi add storage alanında Pool içerisine diskleri eklemek için ilerliyoruz, ardından Görsel-3’de bulıunan ekrandan ekleyeceğimiz diskleri, sayısını ve RAID modelini seçiyoruz. (Default ve IBM önerisi Distributed RAID-6)

    Görsel-2

    Görsel-3

    Aynı işlemleri 2. Lokasyondaki storage üzerinde de tekrarlıyoruz, ardından primary olarak kullanacağımız storage a dönüp, Görsel-4 üzerindeki gibi, iki storage arasındaki partnership tanımını yapmak üzere, Copy services altındaki Partnership and remote copy alanına gidiyoruz.

    Görsel-4

    Görsel-5’de görülen ekran karşımıza çıkacak ve bugün konumuz HA olduğu için 2-site partnership seçerek ilerliyoruz.

    Görsel-5

    Görsel-6’da görülen ekrandan network bağlantısı tam yapılmış ise 2. Lokasyondaki cihaz partner system olarak seçeneklerde çıkacak ve onu buradan seçebiliriz. Link ayarlarını görseldeki alanda demo ortamı olduğundan 32000 Mbps bıraktım ama siz bunu hesaplayıp planlayabilirsiniz. Use policy based replication alanını işaretleyip, create ile partnership oluşturuyoruz.

    Aynı işlemi 2. Lokasyon storage üzerinde yapıp, 1. Lokasyondaki cihazı seçerek tamamlıyoruz.

    Görsel-6

    Görsel-7’deki gibi Pool alanına dönüp tanımladığımız pool için Add Pool Link diyerek 2 lokasyon arasında pool için link oluşturuyoruz. Burada local sistemde ve 2. Lokasyonda aralarında bağlantı yapılacak doğru pool seçimi yapmamız önemli. Provisioning policy olarak özel bir planlama yoksa sol alttaki alanı işaretleyerek standart policy kullanabilirsiniz.

    Görsel-7

    İki storage arasındaki bağlantı tanımı, iş birliği yapıldıktan sonra sıra FlashSystem Grid yapısında bahsettiğim Storage partition oluşturmaya geldi.  Görsel-8’de görüleceği gibi sol attan storage partitions alanına gidip, Create partition ile ilerliyoruz.

    Açılan Create new storage partition ekranında bir HA senaryosu kurduğumuz için High-availability replication seçiyoruz, daha önce tanımladığımız partnership’i seçip, üzerinde çalıştığımız storage management mı sorusuna planlamaya göre cevap veriyoruz ama önerilen her zaman primary site storage’ın management olmasıdır, dolayısıyla aksi bir plan yoksa alanı işaretleyip, ilerliyoruz.

    Görsel-8

    Sıradaki işlem quaorum tanımlama, kısaca nedir quorum?

    Politika bazlı yüksek erişilebilirlik (PBHA) sistemi, ana lokasyonun quorum bağlantısını kaybetmesi durumunda otomatik olarak devreye girer.

    • Yedek lokasyon devreye girer: İkinci lokasyon kontrolü üstlenerek uygulamalarda ve veri erişiminde kesinti yaşanmasını önler. ( Görsel-9)
    • Ana lokasyon kapatılır: Veri tutarsızlıklarını önlemek için ana lokasyon devre dışı bırakılır.

    Bağlantı yeniden sağlandığında, değişim hacmi (change volume) adı verilen geçici depolama alanındaki değişiklikler senkronize edilir. Bu işlem tamamlandığında, yüksek erişilebilirlik sorunsuz bir şekilde yeniden sağlanır ve veriler güvende kalır.

    Görsel-9

    Görsel-10’daki gibi IPv4 uygulamayı indirip mümkünse 2 lokasyondan da tamamen bağımsız bir sisteme kurulmalı, birden fazla da kurabilirsiniz.

    Görsel-10

    Sıra Görsel-11’deki Replication policy tanımına geldi, bugünkü konumuz olan HA e uygun 2-Site High Availability seçip primary-secondary site kontrolünü yapıp ilerliyoruz.

    Görsel-11

    Sonraki ekran oluşturulan partition’ın ismini yazıp ilerliyoruz. Ardından volume grup, volume ve host tanımlarını da buradan yapıp ilerleyebiliriz. Görsel-12 gibi volume grupları ve içerisindeki volume tanımlarını yapabiliriz. Bunlar sonradan da güncellenebilir olacaktır.

    Görsel-12

    Son olarak storage partition alanı altında yeni oluşturduğumuz partition a tıkladığımızda iki lokasyona arasındaki HA partitionı’ı Görsel 13 gibi görebiliriz. Bu alanda tanımlanan volume, volume grup, hostları da takip edip, yönetebilirsiniz.

    Görsel-13

  • Geçmişten Günümüze: IBM Replikasyon ve Yüksek Erişilebilirlik Çözümleri Serisi-2

    Policy-based replication kısmını açıklayıp, içerisinde gelen Policy-based HA ile Hyperswap yerine iş sürekliliğini nasıl sağlıyoruz ona gelelim.

    Policy-based replication üç çalışma moduna sahiptir:

    1. Change Recording mode: Production sistemi üzerindeki değişiklikleri izler ancak recovery sisteme çoğaltma yapmaz.
    2. Journaling mode: Production sistem üzerindeki değişiklikleri sırasıyla izler ve çoğaltır. ( Görsel 3)
    3. Cycling mode: Yeni host write işlemlerini izler ve production volume’un snapshot’ından periyodik olarak çoğaltır.

    Journaling mode düşük RPO sağladığı için genelde ilk tercihtir, ancak bandwidth yetersizliği nedeniyle gereken write volume sağlanamazsa sistem otomatik olarak cycling mode‘a geçer. Bu modda, production volume’un periyodik snapshots‘ı alınır ve sadece yapılan değişiklikler çoğaltılır. Bu yaklaşım veri transferini azaltırken potansiyel veri kaybını biraz artırabilir. Cycle sıklığı, hedef RPO‘ya göre ayarlanır; daha sık cycle’lar veri kaybını azaltır ama daha fazla bandwidth gerektirir. Sistem bu dengeyi, belirlenen RPO‘yu karşılayacak şekilde otomatik olarak optimize eder.

    Görsel 3- Journaling mode ile politika tabanlı replikasyon

    En büyük avantajlardan birisi bu yapı içerisinde, bir önceki FlashSystem Grid yazımda bahsettiğim Görsel-4’de tekrar görebileceğiniz partition mobilite ile farklı partitionları farklı modlarda kullanabilirsiniz.

    Görsel-4

    Policy-based HA (PBHA), aktif/aktif çalışan bir yüksek erişilebilirlik çözümüdür. HA devredeyken, her iki volume kopyası da kullanılabilir ve host’lar I/O işlemlerini istediği kopyaya gönderebilir. Bu sırada kopyalar arasında tam senkronizasyon sağlanır.

    Bu çözümde, synchronous replication kullanılarak üretim volume kopyaları arasında veri eşitliği korunur. Volume groups, birbiriyle bağlantılı uygulamalar arasında tutarlılığı yönetmek için kullanılır. Ayrıca, tüm site’lerden gelen host’ların aynı üretim verisine erişebilmesi gerekir. Bunun için IBM Storage Virtualize, Storage Partitions kavramını sunuyor. Storage Partitions, volume groups, host’lar ve mapping’lerden oluşan bir yapı olarak, tüm verinin organize ve erişilebilir olmasını sağlıyor. Görsel-5 e yapıyı daha iyi anlamak için bakabilirsiniz

    Görsel-5

    Storage partitions sayesinde host’ları volume group kopyalarına manuel eşleştirmek gerekmez; her şey hazırdır. UID aynı olduğu için volume tanıma sorunları da yaşanmaz. HA, verilerin yanı sıra storage partition konfigürasyonlarını (host tanımları ve eşleştirmeler) da değişiklik olduğunda otomatik olarak uzak site’e aktarır.

    Her partition için bir preferred management system seçilir; bu sistem, bağlantı kesilse bile yönetimin devamını sağlar. Host lokasyonları tanımlıysa, işlemler lokal olarak yapılır ve her site kendi verisine erişir. Bu düzenin sorunsuz işlemesi için host lokasyonlarının doğru yapılandırılmış olması önemlidir.

    IBM Storage Virtualize’in policy-based replication özelliği, verileri recovery site’a kopyalayarak veri kaybını önler ve RPO‘yu minimum seviyeye indirir. Policy-based HA ise kesintisiz iş sürekliliği sağlar ve üretim sitesinden recovery site’a otomatik failover ile kesinti riskini ortadan kaldırır. Görsel-6 ya karşılaştırma tablosu için bakabilirsiniz.

    Görsel-6

  • Geçmişten Günümüze: IBM Replikasyon ve Yüksek Erişilebilirlik Çözümleri Serisi-1

    2018 yılında yazdığım ve hala çokça ilgi gören makaleyi güncelleme zamanı geldi. Depolama dünyasındaki yenilikleri daha kapsamlı ve anlaşılır bir şekilde ele almak için bu seriyi üç kısma ayırarak paylaşacağım:

    • 1. Kısım: IBM olarak geçmişte replikasyon ve yüksek erişilebilirlik (HA) senaryolarında neler yaptık?
    • 2. Kısım: Politika bazlı replikasyon nedir? Hangi modları sunuyoruz, nasıl çalışıyor ve avantajları nelerdir?
    • 3. Kısım: PBHA (Policy-Based High Availability) uygulamasını nasıl yapacağımızı kısa ve öz bir şekilde açıklayacağız.

    İlk bölümde, yeniliklere geçmeden önce geçmişi hatırlayalım: Policy-Based Replication (Politika Bazlı Replikasyon) nedir? Hangi modlar sunuluyor? HA dışında başka hangi seçenekler mevcut? Bu sorulara yanıt vereceğiz.

    Ayrıca, IBM Hyperswap yerine artık Policy-Based HA modelini sunuyoruz. Bu yeni modelin sunduğu avantajları, iş sürekliliği ve veri yönetiminde nasıl fark yaratacağını, kurulum sürecinin Hyperswap kadar kolay olduğunu bu seride adım adım ele alacağız.

    Eskiden IBM Storage Virtualize’de synchronous replication (senkron replikasyon), Metro Mirror hizmetiyle sağlanıyordu. Ancak, coğrafi olarak uzak lokasyonlarda yüksek RTT (Round-Trip Time) nedeniyle bu yöntem pratik olmuyordu. (Görsel-1) Bu durumda asynchronous replication (asenkron replikasyon) devreye giriyordu.

    Asenkron modda, recovery site’daki veriler production site’ın gerisinde kalabiliyor, çünkü son cycle’dan sonra yapılan değişiklikler henüz aktarılmamış olabiliyor. Örneğin, Recovery Site “A” verisini işlerken Production “B” yazıyorsa, “B” ancak bir sonraki cycle’da recovery site’a ulaşıyor. (Görsel-2)

    Bu eski versiyonlarda, asynchronous replication için iki temel hizmet kullanılıyordu:

    1. Global Mirror: Temel seviyede asenkron replikasyon sağlıyordu.
    2. Global Mirror with Change Volumes (cycling-mode): Snapshots kullanarak daha gelişmiş bir replikasyon yöntemi sunuyordu ve şu anki sistemle benzer bir mantıkla çalışıyordu.

    Görsel-1 – Senkron replikasyon ve RTT etkisi

    Görsel-2 – Döngü tabanlı asenkron replikasyon

    Serinin 2. kısmında yeni gelen Policy-based replication kısmını açıklayıp, içerisinde gelen Policy-based HA ile Hyperswap yerine iş sürekliliğini nasıl sağlıyoruz ona bakacağız.

    Sıfır RPO ve sıfır RTO