Soğuk Veri Nedir?

Soğuk veri, nadiren erişilen, ancak saklanması gereken veriler olarak tanımlanır. Genellikle arşivleme, uzun vadeli saklama ve uyumluluk gereksinimleri için tutulur. Soğuk veri, finansal belgeler, eski müşteri verileri, arşivlenmiş e-posta ve log dosyaları gibi çeşitli biçimlerde olabilir. Bu tür verilerin maliyet etkin bir şekilde depolanması, işletmeler için büyük önem taşır.

IBM’in Soğuk Veri Çözümleri

IBM Cloud Object Storage

IBM Cloud Object Storage, büyük miktarlarda veriyi ekonomik ve güvenli bir şekilde depolamak için ideal bir çözümdür. Bu hizmet, veri parçalama ve coğrafi dağıtım teknikleri kullanarak yüksek dayanıklılık ve erişilebilirlik sağlar. Soğuk veri için özel olarak tasarlanan arşivleme katmanları, maliyetleri minimize ederken veri güvenliğini en üst düzeye çıkarır.

IBM Spectrum Archive

IBM Spectrum Archive, Linear Tape File System (LTFS) teknolojisini kullanarak manyetik bantlarda veri saklama çözümleri sunar. LTFS, bant depolamayı daha erişilebilir ve kullanıcı dostu hale getirir. Bu teknoloji, uzun vadeli veri saklama ihtiyaçlarını karşılamak için düşük maliyetli ve güvenilir bir yöntem sunar.

IBM Spectrum Scale

IBM Spectrum Scale, büyük ölçekli veri yönetimi ve depolama çözümleri sunar. Bu yazılım tanımlı depolama çözümü, yüksek performanslı veri erişimi ve esneklik sağlar. Spectrum Scale, farklı veri katmanları arasında otomatik veri taşımayı destekler, böylece sık erişilen veriler hızlı depolama katmanlarında tutulurken, soğuk veri daha ekonomik depolama seçeneklerine taşınır.

IBM Ceph Depolama Çözümü

IBM, açık kaynaklı Ceph depolama platformunu kullanarak esnek ve ölçeklenebilir bir çözüm sunar. Ceph, nesne, blok ve dosya depolama hizmetlerini tek bir birleşik platformda sunar. IBM’in Ceph çözümü, büyük veri setlerini düşük maliyetle yönetmek için idealdir ve soğuk veri depolama ihtiyaçlarını karşılamak için optimize edilmiştir.

Sonuç

IBM, soğuk veri yönetimi ve depolama konusunda çeşitli çözümler sunarak işletmelerin verilerini daha verimli ve maliyet etkin bir şekilde yönetmelerine yardımcı olmaktadır. IBM Cloud Object Storage, Spectrum Archive, Spectrum Scale ve Ceph gibi yenilikçi çözümler, işletmelerin veri depolama stratejilerini optimize etmelerini sağlar. Bu çözümler, verilerin güvenli, erişilebilir ve uygun maliyetli bir şekilde saklanmasını garanti eder.

IBM’in soğuk veri çözümleri hakkında daha fazla bilgi almak için IBM’in resmi web sitesini ziyaret edebilir veya doğrudan IBM temsilcileriyle iletişime geçebilirsiniz.

Konuyla ilgili diğer makalelerede göz atabilirsiniz.

IBM Spectrum Scale

IBM Cloud Object Storage

IBM COS Performans Planlaması yazımın 2. kısmına hoşgeldiniz bu sefer ufak bir yazı olacak diyebilirim. Bu yazı içerisinde network konularına ve genel olarak performans planlamasının ölçütleri hakkında bilgi vermeye çalışacağım.

Öncelikle 1. bölümü okumak isteyenler lütfen BURAYA

IBM COS Network Performansı

IBM COS ile ağ performansını optimize ederken dikkate alınması gereken kilit noktalar, jumbo frameler ve NIC birleştirmedir.

Jumbo Frame

Jumbo frame kullanımının ana avantajı, optimum ağ kullanımı ve daha yüksek verim sağlayan TCP işleme için gerekli CPU kaynak kullanımını azaltmasıdır. Jumbo frameler, standart framelerden daha büyük olduğundan, daha az frame’e ihtiyaç duyulur ve bu nedenle CPU işleme kaynağı kullanımı azalır.

Bununla birlikte, daha büyük bir frame, standart bir 1500 maksimum aktarım birimi (MTU) Ethernet frame’inden yaklaşık 6 – 7 kat daha fazla bir gecikme sağlar. Bu sorun, uygulama yanıt süresini etkileyebilir ve yüksek performanslı bilgi işlem (HPC), multimedya, video akışı, VoIP ve web hizmetleri gibi hassas uygulamalar bu gecikme nedeniyle etkilenebilir.

Jumbo frameler de tasarıma bir karmaşıklık katar ve bu konu kararınızda dikkate alınmalıdır. Örneğin, Accesorler için client kanalında genel interneti kullanıyorsanız, internet üzerinden jumbo frameler geçirmek bir sorun olabilir.
Tepki süresi birincil endişeniz ise (iş hacmi değil), standart MTU’yu kullanın; Aksi takdirde, jumbo framelerin kullanımını düşünebilirsiniz.

Belirli bir kanal için, MTU ayarları tüm sistem ve tüm anlık anahtarlar arasında tutarlı olmalıdır. Bu tutarlılık, performansı etkileyebilecek paket parçalanmasını önler. MTU ayarı, IBM COS’a bağlanan istemciler ve IBM COS’nin istemciye yönelik arabirimleri arasında da tutarlı olmalıdır. Accesor düğümleri ve Slicer düğümleri, bağlı NIC’lerle yapılandırılabilir.

İpucu: IBM COS için varsayılan MTU ayarı 1500’dür ve gerekirse jumbo frameleri (MTU=9000) destekleyecek şekilde değiştirilebilir.

NIC bonding

IBM COS NIC’leri, yük dengeleme (LACP) ve yedeklilik için bağlanabilir. Yük dengeleme kullanılıyorsa, ağ anahtarları COS bağlantı noktalarındaki ayarlarla eşleşecek şekilde doğru şekilde yapılandırılmalıdır.

Toplu bağlantılar arasındaki trafik akışını optimize etmek için çeşitli karma algoritmalar kullanılabilir. Uygun karma algoritma, cihaza gelen trafik ve cihazdan çıkan trafik için farklı olabilir.

IBM COS Performans Ölçümü

IBM, müşterilerin ve üçüncü kişi bütünleştiricilerin, müşteri uygulamasında herhangi bir performans testi çalıştırmadan önce her zaman bir IBM COS sisteminin performansını temel almasını önerir.

IBM COS performansının temel çizgisini oluşturmak için Nesne Oluşturucu (OG) gibi bir yük oluşturucu kullanılabilir.
OG aracı, bir Accesser düğümüne karşı HTTP testi için geleneksel bir istemci olarak kullanılabilen açık kaynaklı bir Java programıdır.

Genel OG deposu GitHub.com’da bulunabilir ve bu web sayfasındaki sürüm yapıları mevcuttur.
OG, bir Windows veya Linux ana bilgisayar işletim sisteminden çalıştırılabilir ve aşağıdaki işlevleri gerçekleştirme yeteneği de dahil olmak üzere çok çeşitli işlevleri destekler:

• Thread sınırlı veya OPS modlarında çalıştırın.
• Tek bir çağrıdan birden çok dosya boyutu aralığını destekleyin.
• PUT, GET, DELETE, LIST, HEAD ve Multipart Upload trafiğinin farklı karışımlarını destekleyin.
• OG, aracın oluşturduğu rastgele kaynak verileri oluşturur.

Tercih edilen uygulama: Herhangi bir performans testi çalıştırmadan önce bir kasayı kısmen doldurmak en iyi uygulama olarak kabul edilir.

• Doldurma, planlanan iş yüküyle eşleşmeli ve sistem performansındaki bir değişikliğe yanıt veren (sabit bir OPS yük oluşturucu yerine) iş parçacığı tabanlı bir yük oluşturucu kullanmalıdır.
• Doldurma, istikrarlı performans elde edilene kadar devam etmelidir.
• IBM COS sistem temeli, planlanan üretim iş yüküyle aynı nesne boyutlarını ve iş akışını kullanmalıdır.

Aşağıdaki yaygın performans testi türleri mevcuttur:

OPS testi Dosya boyutu değiştirilirken eşzamanlılık sabit tutulur. Birincil metrikler, saniyedeki işlemler ve aktarım hızıdır.

Latency testi OPS değiştirilirken dosya boyutu sabit tutulur. Birincil metrik gecikmedir.

Smoke testi Dosya boyutları ve işlem türlerinin bir karışımını içerir. Bir eşzamanlılık veya OPS’de çalıştırılabilir modu.

Concurrency testi Eşzamanlılık değiştirilirken dosya boyutu sabit tutulur. Birincil metrik verimdir; ikincil metrik gecikmedir.

Diğer Konular:
Test sonuçlarının geçerli olduğundan emin olmak için performans testi için kullanılan bir sistemi izlemek de önemlidir.
Aşağıdaki noktaları göz önünde bulundurun:

• Test özellikle bozulmuş bir sistemdeki performansa bakmıyorsa, depolama havuzu her zaman hiçbir Slicestor düğümü kapalı ve çekilmiş veya karantinaya alınmış diskler olmadan tam genişlikte olmalıdır.
• Test çalıştırması sırasında yeniden oluşturma yapılmamalıdır.
• Diskler karantinaya alınırsa, disk arızası gerçekleştirilmeden değiştirilmelidir. göç. Ayrıca, test devam ettirilmeden önce yeniden oluşturma işleminin tamamlanmasına izin verilmelidir.
• Disk yeniden dengelemenin bir faktör olmadığından ve disklerin fazla dolmadığından emin olmak için disk doldurma seviyeleri izlenmelidir.
• Kasa silme işlemi hemen istemciye döner, ancak arka planda çalışması biraz zaman alabilir. Bu nedenle, kasa silme içeren testler, başka bir teste başlamadan önce kasaların silinmesi için yeterli süre tanımalıdır.

Umarım bilgilendirici bir yazı olmuştur. Bir sonraki yazım yine bir kaç bölüm olacak, Güvenlik ve Erişilebilirlik konularının planlanmasına bakalım istiyorum.

Bu arada yazıyı beğendi iseniz, Patreon üstünden bir kahve ısmarlaya bilir veya abone olup yeni yazılarımın ve podcastlerimin gelmesi için bana destek olabilirsiniz.

IBM Cloud Object Storage Kapasite Planlaması isimli yazıma hoş geldiniz, bugün 1 Ocak 2022 , yılın ilk günü size bir yazı paylaşmak istedim. Bu yazı, kapasite planlaması ile ilgili olacak fakat devamında gelecek yazıda ise IBM Cloud Object Storage sisteminin performans planlamasına bakacağız.

via GIPHY

Kapasite planlaması

Bir IBM COS çözümü tasarlanırken, kapasite gereksinimlerinin aşağıdaki yönleri dikkate alınmalıdır:

• Başlangıç kapasite gereksinimi
• Artan kapasite gereksinimi
• Zaman içinde beklenen büyüme oranı

İlk kapasite gereksinimi

Kullanılabilir bir kapasite gereksinimini karşılamak için aşağıdaki öğeler dikkate alınmalıdır:

• Slicestor modeli
• Slicestor Sayısı
• Sürücü boyutu
• Bir site, iki site veya üç site (veya daha fazla) dağıtım
• Olası IDA alternatifleri

İlk kapasite gereksiniminin TB/PB (ondalık) veya TiB/PiB (ikili) için olduğunu doğrulayın:

• 1 TiB = 1.09951 TB
• 1 PiB = 1.1259 PB

2 PB’den küçük sistemler için, Konsantre Dağılma (CD) Modu sistemi, genellikle Standart Dağılma (SD) Modu sisteminden daha uygun maliyetlidir. CD Modu, bir SD Modu sisteminden daha az Slicestor gerektirdiğinden, daha küçük başlangıç kapasitesi (72 TB’dan başlayarak kullanılabilir) sağlar.

Not: Bir CD Modu sistemi, özellikle okumalar için bir SD Modu sisteminden daha düşük performansa sahiptir.
Farklı sürücü boyutlarına sahip çeşitli Slicestor modellerinin ham kapasiteleri, çeşitli Slicestor düğümlerinin ham TB kapasitesini aşağıda bulabilirsiniz.

Önemli: Tek bir aygıt setindeki tüm Slicestor düğümleri aynı modelde olmalı ve aynı boyutta sürücülerle doldurulmalıdır.

Çeşitli Slicestor düğümleri için tipik genel ham başlangıç kapasitesi aralığı

Aşağıda çeşitli Slicestor düğümleri için tipik genel ham başlangıç kapasitesini göstermekteyim. SD Modunda Slicestorlerin kısmen doldurulabileceğini ve dolayısıyla daha büyük Slicestorlerin başlangıç noktasının önemli ölçüde daha küçük olabileceğini unutmayın.

CD Modu ve SD Modu sistemleri için bir ve birden fazla site için tipik genişleme faktörleri;

• Genişleme faktörü = (ham kapasite)/(kullanılabilir kapasite)
• Genişleme faktörü = (IDA genişliği)/(IDA okuma eşiği)

Bir, iki veya üç (veya daha fazla) site için desteklenen IDA’lar

Önemli:Daha büyük bir sürücü boyutu GB başına maliyet açısından daha ekonomik olsa da, daha küçük bir sürücü boyutu sistemde daha fazla iş mili ve daha fazla Slicestor düğümü ve dolayısıyla daha iyi performans sağlar.

Üç site için küçük kapasite yapılandırması örneği

Bu örnekte, bir müşterinin 200 TB kullanılabilir başlangıç kapasitesine ihtiyacı vardır. Üç site için tipik bir IBM COS genişletme faktörü 1.8 – 2.0’dır.

Gerekli ham kapasiteyi belirlemek için gerekli kullanılabilir kapasiteyi tipik bir genişleme faktörü ile çarparak başlayın:

Gerekli ham kapasite = 200 TB × 2,0 = 400 TB

Üç sitede 400 TB ham kapasite için, CD Modunda üç Slicestor 12 düğümü veya altı Slicestor 12 düğümü seçiyoruz. Performans önemli değilse ve en uygun maliyetli çözümü tasarlamak istiyorsak, gerekli kapasiteyi sağlayabiliyorlarsa üç Slicestor 12 düğümü ile ilerlenebiliriz.

Ardından, çeşitli sürücü boyutlarına sahip üç Slicestor 12 düğümü için toplam ham kapasiteyi hesaplıyoruz:

Ham kapasite = (toplam disk sürücüsü sayısı) × (sürücü boyutu)

Aşağıdaki noktaları göz önünde bulundurun:

• 4 TB sürücüler: 36 × 4 TB = 144TB 
• 8 TB sürücüler: 36 × 8 TB = 288TB
• 12 TB sürücüler: 36 × 12 TB = 432TB
• 16 TB sürücüler: 36 x 16 TB = 576TB
• 18 TB sürücüler: 36 x 18 TB = 648TB

Önceki hesaplamalardan, 12 TB sürücülerin gerekli ilk ham kapasite için iyi bir şekilde eşleştiğini görebiliriz.
Üç Slicestor 12 düğümüyle, üç site için olası tek IDA 18/9/11’dir (genişletme faktörü 2.0).

Planlanan sistemin kullanılabilir kapasitesini hesaplayın:

Kullanılabilir kapasite = (ham kapasite) / (genişletme faktörü)

Kullanılabilir kapasite = 432 TB / 2,0 = 216 TB

Üç site için orta kapasite yapılandırması örneği

Bu örnekte, bir müşterinin 3 PB kullanılabilir başlangıç kapasitesine ihtiyacı vardır. Üç site için tipik bir IBM COS genişletme faktörü 1.8 – 2.0’dır.

Gerekli ham kapasiteyi elde etmek için gerekli kullanılabilir kapasiteyi tipik bir genişleme faktörü ile çarparak başlayın:

Gerekli ham kapasite = 3.000 TB × 2,0 = 6.000 TB

Üç sitede 6.000 TB ham kapasite için, tamamen veya kısmen sürücülerle doldurulmuş standart dağıtım modunda 12, 15 veya 18 × Slicestor 53 düğümü seçebiliriz

Tablo, yaklaşık 6.000 TB – 7.000 TB arasındaki ham kapasiteleri vurgulamaktadır. Kısmen doldurulmuş seçenekler altın rengiyle ve tam doldurulmuş seçenekler yeşille vurgulanmıştır.

Yalnızca yeni sürücüler ekleyerek kolay yükseltme sağlayan uygun maliyetli bir sistem, her biri 28 x 18 TB sürücülerle doldurulmuş 12x Slicestor 53 düğümüdür. Tablodaki toplam ham kapasite 6048 TB’ı gösterir.

Planlanan sistemin kullanılabilir kapasitesini hesaplayın: Kullanılabilir kapasite = (ham kapasite) / (genişletme faktörü)

Kullanılabilir kapasite = 6.048 TB / 2 = 3.024 TB.

Üç site örneği için büyük kapasite yapılandırması

Bu örnekte, bir müşterinin 20 PB kullanılabilir başlangıç kapasitesine ihtiyacı vardır. Üç site için tipik bir IBM COS genişletme faktörü 1.8 – 2.0’dır. Müşteri ayrıca, veri merkezlerinde fazladan derin raflar kuramayacakları konusunda bilgilendirilir.

Gerekli ham kapasiteyi elde etmek için gerekli kullanılabilir kapasiteyi tipik bir genişleme faktörü ile çarparak başlayın:

Gerekli ham kapasite = 20.000 TB × 2,0 = 40.000 TB

Müşteri derin rafları dağıtamadığından ancak büyük bir kapasite gerektirdiğinden, en iyi seçenek sistemi Slicestor 92 düğümlerine dayalı olarak tasarlamaktır.

Bu boyuttaki bir sistem için, yüksek güvenilirlik ve kullanılabilirlik ile birlikte en düşük genişleme faktörlerini sağladıkları için daha geniş IDA’lara bakma eğilimindeyiz.

Maliyet açısından en verimli sistem, 18 TB sürücülü 24 geniş sistem olacaktır.

Kullanılabilir kapasite = (ham kapasite)/(genişletme faktörü)

• Kullanılabilir kapasite = 39.744 TB / 1.846 = 21.530 TB.
• En yüksek performanslı sistem, 12 TB sürücülü 36 geniş sistem olacaktır.

Kullanılabilir kapasite = (ham kapasite)/(genişletme faktörü)

Kullanılabilir kapasite = 39.744 TB / 1.8 = 22.080

Standart Dağılma modu için kapasite planlamak için alternatif yöntem

Potansiyel Slicestor modellerini ve sürücülerini değerlendirmek için hızlı bir alternatif yöntem, her sürücü seçeneğiyle her Slicestor düğüm modelinin ham kapasitesini listeleyen bir tablo oluşturmaktır.

Aşağıdaki denklem kullanılır:

Gerekli kullanılabilir kapasite = (RT of IDA) × (bir Dilimleyicinin ham kapasitesi)

Not: RT, okuma eşiğini ifade eder.

Önceki 20 PB kullanılabilir kapasite gereksinimi için, artık 20 PB kullanılabilir kapasiteyi eşleştirmek için kaç Dilimleyici düğümü gerektiğini hesaplayabiliriz. Sonuç, bir IDA’nın okuma eşiği ile aynıdır.

Ondalık sayılar en yakın tam sayıya yuvarlanmalıdır. Yukarıda’da listelenen kapasiteler ham olduğundan ve 20 PB kullanılabilir kapasite için kaç Dilimleyici düğümü gerektiğini bilmek istediğimizden, bu Dilimleyici düğüm miktarlarının bir SD Modu IDA’nın okuma eşiğine (RT) eşit olduğunu düşünebiliriz.

Tablodan, 20 PB kullanılabilir kapasite gereksinimini karşılamak için çok sayıda Slicestor 12 düğümünün gerekli olacağını görebiliriz. Slicestor 12 düğümlerini, yalnızca müşteri performans gereksinimleri Slicestor 92 düğümleriyle eşleştirilemiyorsa dikkate almalıyız.

Örnek olarak, yukarıda 20 PB kullanılabilir kapasiteye ulaşmak için 12 TB sürücülerle tam olarak doldurulmuş 18.1 Slicestor 92 düğümüne ihtiyacımız olduğunu göstermektedir. Gerekli Slicestor 92 düğümlerinin sayısını 19’a yuvarlamak, 20PB kullanılabilir kapasite için 12 TB sürücülü 19 Slicestor 92 düğümünün kapasitesinin gerekli olduğu anlamına gelir. 19 sayısı, bir SD Modu IDA’nın okuma eşiği olacaktır.

Hesaplanan bu IDA okuma eşiklerini SD Modunda üç site için desteklenenlerle karşılaştırırız ve şimdi aşağıdaki seçenekler arasından seçim yapabiliriz:

• 6 TB sürücü -> hesaplanan RT 37 -> bu kadar yüksek okuma eşiğine sahip IDA yok
• 8 TB sürücüler -> hesaplanan RT 28 -> bu kadar yüksek okuma eşiğine sahip IDA yok
• 10 TB sürücüler -> hesaplanan RT 22 -> bu kadar yüksek okuma eşiğine sahip IDA yok
• 12 TB sürücüler -> hesaplanan RT 19 -> aşağıdaki listeden olası IDA 36/20/23
• 16 TB sürücüler -> hesaplanan RT 14 -> aşağıdaki listeden olası IDA 27/14/17
• 18 TB sürücüler -> hesaplanan RT 13 -> aşağıdaki listeden olası IDA 24/13/15

Şimdi, aşağıdaki formülü kullanarak bu üç alternatif için kullanılabilir kapasiteyi hesaplayabiliriz:

Kullanılabilir kapasite = (tek Dilimleyicinin ham kapasitesi) × (IDA’nın Eşiği Okuma)

• 12 TB sürücülerle kullanılabilir kapasite = 1104 TB × 20 = 22.080 TB.
• 16 TB sürücülerle kullanılabilir kapasite = 1472 TB × 14 = 20.608 TB.
• 18 TB sürücülerle kullanılabilir kapasite = 1656 TB × 13 = 21.528 TB.

Yukarıda’da gösterildiği gibi, aşağıdaki alternatifleri göz önünde bulundurabileceğimizi görebiliriz:

• 12 TB sürücüler -> IDA 36/20/23
• 16 TB sürücüler -> IDA 27/14/17
• 18 TB sürücüler -> IDA 24/13/15

Yüksek performans istenmiyorsa 18 TB sürücülü seçenek değerlendirilmelidir.

Artan kapasite gereksinimleri

Yeni Slicestor düğümlerinde ekstra kapasiteyi kullanmak için IDA’lar değiştirilmeden kalmalıdır. İlk sistemimizde CD Modu IDA 18/9/11 kullanan paketlerde veriler varsa, yeni donanım eklemesi (aygıt seti) aynı IDA’yı kullanabilmelidir.

Not: Yeni bir aygıt setinde, orijinal aygıt setinden farklı Dilimleyici modelleri (hatta farklı donanım nesilleri) olabilir. Orijinal aygıt setinden başka sürücü boyutlarına da sahip olabilir.

Üç site için küçük kapasite yapılandırması için artan kapasite örneği

Bu örnekte, ilk küçük kapasite yapılandırması, her biri on iki 12 TB sürücüye ve bir CD Modu IDA 18/9/11 olan üç Dilimleyici 12 düğümüne sahip tek bir aygıt setinden oluşuyordu.

Yeni bir aygıt seti, aynı veya farklı Dilimleyici modellerine ve aynı veya farklı sürücü boyutuna sahip olabilir.

Örneğin, 50 TB’lik bir artımlı kapasitenin gerekli olduğunu varsayalım. Sisteme eklenebilecek olası en küçük aygıt seti, her biri 12 adet 4 TB sürücüye sahip üç Slicestor 12 düğümüdür.

Yeni cihaz setinin toplam ham kapasitesi şu şekilde hesaplanır: 3 × 12 × 4 TB = 144 TB

CD Modu IDA 18/9/11’dir; bu nedenle, genişleme faktörü şu şekilde hesaplanır: 18 / 9 = 2.0

To calculate the net capacity increment in this example, we use the following formula:

Net capacity = (raw capacity)/(expansion factor)

Bu formülü kullanarak artık yeni cihaz setinin net kapasitesini hesaplayabiliriz:

Net kapasite = 144 TB / 2.0 = 72 TB

Üç site örneği için mevcut orta kapasite yapılandırması için artımlı kapasite

Bu örnekte, ilk orta kapasite konfigürasyonu, her biri kısmen 28 × 18 TB sürücüler ve SD Mod IDA 12/6/8 ile doldurulmuş 12 × Slicestor 53 cihazlarıyla tek bir cihaz setinden oluşur.

Mevcut cihaz setinde boş sürücü yuvalarımız bulunduğundan, sistem kapasitesini artırmak için bunları kullanmak mantıklıdır.

Örneğin, 1-1.5 PB kullanılabilir artımlı kapasitenin gerekli olduğunu varsayalım.

Mevcut sürücülerle aynı boyutta sürücüler eklemeliyiz. Seçenekler şunlardır:

• 18 TB sürücü sayısını 28’den 41’e yükseltin. Slicestor başına 13 yeni sürücü gereklidir.
• 18 TB sürücü sayısını 28’den 53’e yükseltin. Slicestor başına 25 yeni sürücü gereklidir.

Sürücü eklentisinin toplam ham kapasitesi aşağıdaki formül kullanılarak hesaplanabilir:

(Dilimleyici başına eklenti sürücü sayısı)*(mevcut Dilimleyici sayısı)*(sürücü boyutu)

• Slicestor başına 13x sürücü ekleyin -> 13x 12x 18 TB = 2808 TB ham.
• Slicestor başına 25x sürücü ekleyin -> 25x 12x 18 TB = 5400 TB ham.

Slicestor başına 13 sürücü eklemenin kapasite gereksinimi için daha iyi bir eşleşme olduğunu görebiliriz.

Bu örnekte net kapasite artışını hesaplamak için aşağıdaki formülü kullanın:

Net kapasite = (ham kapasite)/(genişletme faktörü)

Bu formülü kullanarak artık sürücü eklentisinin net kapasitesini hesaplayabiliriz:

Net kapasite = 2.808 TB / 2 = 1.404 TB

Üç site örneği için mevcut büyük kapasite yapılandırması için artan kapasite

Bu örnekte, ilk yapılandırma, her biri 92 × 18 TB sürücülere ve 24/13/15 SD Modu IDA’ya sahip 24× Slicestor 92 düğümlü tek bir cihaz setinden oluşuyordu.

Yeni aygıt seti, aynı veya farklı Slicestor modellerine ve aynı veya farklı sürücü boyutuna sahip olabilir.

Örneğin, 8-10 PB kullanılabilir artımlı kapasitenin gerekli olduğunu varsayalım. Sisteme eklenebilecek mümkün olan en küçük cihaz seti, 24/13/15 mevcut kasa IDA’sını desteklemek için 24× Dilimleyici düğümleridir.

SD Modu IDA, 24/13/15; bu nedenle, genişleme faktörü 24 / 13 = 1.846’dır. Ardından, 24× Slicestor 92 düğümlerinin, 14.768-18.460 TB ham kapasiteye eşit olan gerekli 8-10 PB kullanılabilir kapasiteyi sağlayıp sağlayamayacağını araştırıyoruz.

Ham kapasite gereksinimiyle eşleşen seçenekler altın (kısmen doldurulmuş) veya yeşil (tam doldurulmuş) olarak vurgulanır.

Mevcut sisteme doğrusal performans ölçeklendirmesi sağlayacağından, tam doldurulmuş Dilimleyicilerle seçeneğin seçilmesi tavsiye edilir.

Bu örnekte net kapasite artışını hesaplamak için aşağıdaki formülü kullanın:

Net kapasite = (ham kapasite)/(genişletme faktörü)

Bu formülü kullanarak artık yeni cihaz setinin net kapasitesini hesaplayabiliriz:

Net kapasite = 17.664 TB / 1.846 = 9.569 TB

ÖZET

Kapasite gereksinimlerine dayalı bir IBM COS çözümü tasarlamaya başlamak kolaydır, ancak hiçbir zaman tek tasarım kriteri olmamalıdır. Nihai çözüme karar vermeden önce performans, güvenilirlik ve kullanılabilirlik de dikkatlice düşünülmelidir. Geleceğe daha yakından bakmak anlamlıdır, çünkü başlangıçtaki sistem yalnızca bugünün kapasite gereksinimi için değil, 1-2 yıl içinde gerekmesi beklenenler için boyutlandırılırsa bazen daha iyi performans ve daha düşük genişleme faktörlerine ulaşılabilir.

İpucu: Kapasiteye dayalı bir tasarım, genellikle, başlamak için gerekenden daha fazla gelecekteki artan kapasite gereksinimlerinden etkilenir. Gerekli kapasite eklentilerinin başlangıç kapasitesinin yarısından az olduğu önceden biliniyorsa, bu bilgi tasarıma dahil edilmelidir.

Not: IBM Çalışanları ve Çözüm Ortakları, bir IBM COS sisteminin kapasite planlaması için IBM Storage Modeller aracını kullanabilir. Storage Modeller’a erişimin, IBM Kimliğinizi kullanarak kayıt işlemini tamamlamanızı ve bir PartnerWorld profili oluşturmanızı gerektirdiğini unutmayın.

Diğer IBM Cloud Object Storage Yazılarım için BURAYA

Kullanım Senaryoları 1 : Internet of Things

Farklı IoT cihaz verileri, IoT platformları aracılığıyla uzun vadeli depolamaya, canlı panolara ve gerçek zamanlı sunumlara dönüştürülür.

Aşağıdaki grafikte gösterildiği gibi, Veri bağlantısı ve güvenli dönüşüm, verileri Spark aracılığıyla IBM COS’a aktaran REST API, MQTT ve Kafka gibi bir bağlantı ve pipeline framework’ü aracılığı ile işlenir.

Bu müşteri etkileşimi odaklı modellere genellikle IBM COS aracılığıyla gerçek zamanlı verilerin depolandığı, alındığı ve arşivlendiği arka SoR sistemine bağlı olan SoE olarak bahsedilir.  Bu çözümler IoT platformunu kullanarak çeşitli endüstriler, evler ve şehirlerdeki kullanıcıların etkinlikleri izlenmesine ve cihazları kontrol etmesine yardımcı olur.

Neden IBM Cloud Object Storage?

• IBM COS, IoT içerik havuzunu, gerçek zamanlı erişilebilir verileri, büyük görüntüleri ve video dosyalarını depolayabilir.
• IBM COS’ta depolanan verilere, IoT aygıtları, uygulamaları ve ön uç tüketiciler için her zaman her yerden erişilebilir.
• IBM COS, şirket içi bulut verileriyle çalışır, veri kökenini görselleştirir ve IoT platformlarıyla bütünleştirilirken uygulamaları verilerle besler.

Kullanım Senaryoları 2 : Analitik ve Cognitive Sistemler

Bilişsel sistemler(Cognitive), kitaplar, e-postalar, tweetler, dergiler, bloglar, resimler, ses ve videolardaki görüntüler, doğal dil ve sesler gibi yapılandırılmamış bilgileri “anlayabilir”. Anlamın kilidini açarlar çünkü onun üzerinden akıl yürütebilirler ve bize tartıp düşünmemiz için yeni bağlamlar verirler. Bu verilerin saklanması için depolama alanlarına ihtiyaç duyulabilmektedir.

Büyük hacimli yapılandırılmamış verileri depolamak için farklı uygulamalar gelişti. Daha fazla makine verisi oluşturulmaktadır ve daha ileri analizler ve olası bilişsel kullanımlar için depolanmalı ve korunmalıdır. Bu tür verileri oluşturan yazılım uygulamaları, maliyet etkin bir şekilde petabayt ve daha büyük ölçeklendirme becerisiyle taşıyıcı sınıfı sistem güvenilirliği ve veri güvenliği sağlamak için IBM COS ile birlikte çalışır. Bilişsel sistemler, IBM COS kullanarak büyük hacimli verileri depolar ve işler ve diğer analitik hizmetleriyle bütünleşir.

Neden IBM Cloud Object Storage?

IBM COS, aşağıdaki nedenlerden dolayı Cognitive altyapı çözümleri için çok uygundur:

• IBM COS, Cognitive bir altyapı üzerinde devreye alınan Cognitive bir çözümle şirket içi ve bulut verileriyle çalışır.
• IBM COS’ta depolanan verilere, IoT aygıtları, uygulamaları ve ön uç tüketiciler için her zaman her yerden erişilebilir.
• IBM COS, taşıyıcı sınıfı sistem güvenilirliği, kullanılabilirliği ve ölçeklenebilirlik özelliklerine sahiptir

Kullanım Senaryoları 3 : Yedekleme Alanı

IBM Spectrum® Protect, Commvault, Veeam, Veritas Netbackup veya Rubrik gibi çeşitli kurumsal yedekleme uygulamaları, IBM COS üzerinde yedeklemelerin depolanmasını destekler.

Bazı uygulamalar 1. bazıları ise 2. kopya olarak yedek gönderimi yapabilirler.

Neden IBM Cloud Object Storage?

IBM COS, backup ve repository için mükemmel bir çözümdür.

IBM COS, kuruluşların büyük, maliyetli depolama dizilerini ve manyetik bant silolarını yönetmekten uzaklaşmalarına ve bunun yerine verileri IBM COS’ta depolayan ya da doğrudan IBM COS’a yedekleyen depolama açısından yedekleme sunucularını devreye almalarına olanak tanır. Esneklik özellikleri, iş gereksinimlerine ve yedekleme yazılımı kapasitesine bağlı olarak işletmelerin replikasyondan uzaklaşmasına (bu da depolama gereksinimlerini azaltır) veya IBM COS’u verilerin düşük maliyetli bir üçüncül kopyası olarak kullanmasına olanak tanır. Doğal “sonsuz” depolama havuzu, kapasite yönetiminin artık zor ve zaman alıcı bir görev olmadığı anlamına gelir;

Çoğu büyük yedekleme satıcısının veri tekilleştirme yeteneği, fiziksel kapasite gereksinimlerini tamamen “hidratlanmış” veri kümesinin bir kısmına düşürür. Teyp ıslahı, rotasyonu, ofsiting ve aktarımın yönetilmesi, bir nesne mimarisinde gereksiz hale gelir, bu da yedekleme yöneticilerinin bu yoğun kaynak gerektiren görevleri yönetmek ve izlemek yerine katma değerli işler gerçekleştirmesini sağlar.

Kullanım Senaryoları 4 : Aktif – Aktif

Etkin arşiv, yasal belgeler ve finans belgeleri gibi önemli ancak nadiren erişilen verileri şeffaf bir şekilde depolayan bir veri deposudur. aktif arşiv uygulaması veya temeldeki depolama katmanı tarafından siteler arasında verilerin çoğaltılmasıyla, pahalı olmayan disk sistemleri ve teyp karışımından oluşan eski bir aktif arşiv sistemini göstermektedir.

Esneklik, kullanılabilirlik ve düşük maliyet gereksinimleri bu kullanım senaryosunun anahtarıdır ve genellikle bu tekrarlanan yaklaşımı zorunlu kılar. Çoğaltma ihtiyacı, yedek kopyalar sayılmadan önce bile en az iki veri kopyası ile sonuçlanır. Veri replikasyonu dikkatli bir şekilde izlenmelidir, çünkü bunun yapılmaması sistem esnekliğini azaltır.
Teybin çözümün bir parçası olduğu durumlarda, mimarlar, ilk alım ve geri çağırma için yeterli disk hazırlama alanının mevcut olduğundan emin olmalıdır. Bu bileşenlere hizmet vermek için yeterli teyp sürücüleri de dahil edilmelidir. Ek olarak, uygulama, meşgul bir bant sisteminin yaşayabileceği uzun geri çağırma süreleriyle ilgilenmelidir.

Neden IBM Cloud Object Storage?

• Veri katmanları, verilerin doğrudan IBM COS havuzundan gönderilebilmesi veya alınabilmesi için azaltılır veya ortadan kaldırılır.
• Alan kaybı esnekliği, çoğaltma yerine coğrafi olarak dağınık silme kodlaması yoluyla elde edilir.
• Aşağıdaki temel faydaları sağlayan IBM COS’un coğrafi olarak dağınık yapısı:
  • Birden çok kopya olmaksızın saha hatası kaybı esnekliği, kapasite gereksinimlerini büyük ölçüde azaltır ve çoğaltmayı izleme ihtiyacını ortadan kaldırır.
  • Birincil ve ikincil (salt okunur) kopya kavramının kaldırılması, bir sitenin veya bir siteye erişimin kaybedilmesini içeren bir felaket anlamına gelir, herhangi bir geleneksel yüksek kullanılabilirlik süreci gerektirmez (örneğin, ikinciye yük devretme, ikinciye yükseltme okuma/yazma erişimi, ters çoğaltma, birincil salt okunur düzeyine indirgeme veya yeniden çalışma sırasında tersi).
• Veri katmanlarının düzleştirilmesi, kullanıcıların beklentisi olan basitleştirilmiş yönetim ve tek tip dosya erişimi sağlar. Dosya yaşı veya türünden bağımsız olarak veri erişim hızı aynıdır.
• Büyük bir giriş alanını yönetme ihtiyacı, veriler doğrudan IBM COS’tan kullanıcıya okunabildiğinden veya akışa alınabildiğinden, bu kullanıcı daha sonra dosyayı yerel olarak görüntüleyebilen veya düzenleyebilen ve ardından etkin arşiv sistemi aracılığıyla karşıya yükleyebilen kullanıcıya genellikle kaldırılır veya büyük ölçüde azaltılır.
• Geleneksel depolama sistemlerinde mevcut olan kapasite sınırlamaları, uygulamalar “sınırsız” bir depolama havuzuna erişebildiğinden büyük ölçüde ortadan kalkar. Bu nedenle, mali planlama için kapasite kullanımının ölçülmesi gerekse de, depolama altyapısının yönetimi ve tasarımı artık uygulama, sistem yöneticileri veya mimarlar için bir yük olmaktan çıkıyor.
• İyileştirilmiş operasyonel basitlik, azaltılmış kapasite ve artan esneklik, geleneksel şirket içi veya çoğaltma tabanlı bulut tabanlı dağıtımlarla karşılaştırıldığında, aktif bir arşiv sistemi için tipik olarak daha düşük toplam sahip olma maliyeti (TCO) ile sonuçlanır.

Kullanım Senaryoları 5 : Kurumsal Dosya Hizmetleri

Kurumsal dosya hizmetleri, ilk uygulamaların yerel makine erişimiyle sınırlı olduğu on yıllardır var olmuştur. Kurumsal BT’ye olan bağımlılık arttıkça, merkezi dosya hizmetlerine duyulan ihtiyaç belirgin hale geldi ve birkaç satıcı bu gereksinimleri karşılamak için çeşitli cihazlar piyasaya sürdü.

Aşağıdaki noktaları MUTLAKA göz önünde bulundurun:

• Dizi esnekliği, temel blok depolamadaki RAID şemaları aracılığıyla elde edilir ve çok bölgeli dayanıklılık, çoğaltma yoluyla elde edilir. RAID şemalarına bağlı olarak, büyük ölçekli veri koruması, özellikle büyük kapasiteli dönen disk sürücülerinde hantal hale geldi. Aynı RAID şeridindeki bir veya iki diskin kaybı veri kaybına neden olabileceğinden, yönetilmesi önemli yönetici kaynakları gerektiren esnekliği sağlamak için veri koruması için daha fazla disk gerekir.
• Çok bölgeli veri esnekliği, önemli ağ bant genişliği kullanarak ve depolanan verinin kapasitesinin en az iki katına ihtiyaç duyarak veri çoğaltmayı gerektirir.
• Ayrıca yedek depolama için 3 – 5 kat daha fazla kapasite gerekir.
• Yüksek düzeyde, dosya erişim sistemleri, verileri birçok kullanıcı, iş istasyonu ve sunucu arasında paylaşılan dizinler, alt dizinler ve dosyalar halinde yapılandırır. Güvenlik, kullanıcı ve grup kavramlarına dayanmaktadır. Tipik olarak, bir meta veri deposu bu bileşenler arasındaki ilişkiyi depolar.
• Özellikle NAS sistemleri olgun ve iyi anlaşılmış olsa da, bu sistemlerin temelindeki mimari, kullanıcılar, uygulamalar ve sensörler tarafından üretilen çok büyük miktarda veri nedeniyle bir takım zorluklar doğurmaktadır.
• Denetleyici-muhafaza ölçeklendirme yaklaşımı, bir kümenin içerebileceği NAS kafalarının sayısıyla ilgili katı sınırların var olduğu anlamına gelir ve bu, tek bir ad alanında kullanılabilen kapasiteyi sınırlar. Bu yaklaşım, işletmeler içinde birkaç ayrı depolama adası yaratır. Bu sorun, modern depolama sistemlerinin çözmek için tasarlandığı şeydir.
• Dosya işlemleri için meta veri erişimine olan bağımlılık, bu bileşene çok büyük bir yük getirebilir. Özellikle milyarlarca nesne içeriyorsa, büyük dosya tabanlı sistemlerde genellikle bir tıkanıklık noktası olabilir.
• Denetleyici-muhafaza ölçeklendirme yaklaşımı, bir kümenin içerebileceği NAS kafalarının sayısıyla ilgili katı sınırların var olduğu anlamına gelir ve bu, tek bir ad alanında kullanılabilen kapasiteyi sınırlar. Bu yaklaşım, işletmeler içinde birkaç ayrı depolama adası yaratır. Bu sorun, modern depolama sistemlerinin çözmek için tasarlandığı şeydir.
• Dosya işlemleri için meta veri erişimine olan bağımlılık, bu bileşene çok büyük bir yük getirebilir. Özellikle milyonlarca ila milyarlarca nesne içeriyorsa, büyük dosya tabanlı sistemlerde genellikle bir tıkanıklık noktası olabilir.

IBM COS tabanlı bir mimari, bu zorlukların üstesinden gelir ve aşağıdaki işlevler de dahil olmak üzere dosya hizmetleri için birçok kullanım senaryosu sağlar:

• Genel amaçlı dosya hizmeti, SMB/CIFS ve NFS gibi standart protokollerin yanı sıra Nasuni, Panzura, CTERA gibi genel amaçlı dosya ağ geçitleri aracılığıyla kullanıcı dosyası ve uygulama erişimi sağlar.
• IBM Cloud Object Storage Dosya Erişimi (COS FA) Bu, IBM Cloud Object Storage for Active Archiving kullanım senaryolarında dosyaları depolamak ve almak için eski uygulamalara SMB ve NFS protokolü arabirimi sağlayan ağ geçidi yazılımıdır. Arka uç IBM COS kovası uç noktasının şirket içinde veya IBM Public Cloud’da olabileceği bir sanal makine olarak şirket içinde devreye alınır.
• Yüksek performanslı bilgi işlem, IBM Spectrum Scale gibi dolaylı olarak yüksek performans için tasarlanmış protokoller üzerinden paralellik ve yüksek hızlı ağ ara bağlantısı kullanarak olağanüstü performans ve ölçeklenebilirlik sağlar.
• Dosya senkronizasyonu ve paylaşımı, web arayüzlerini, aracıları kullanarak kullanıcı dosya paylaşım yetenekleri sağlar. iş istasyonlarında ve mobil cihazlarda yazılım ve bazen NAS hizmetleriyle bağlantılıdır.

Dosya hizmetleri için IBM COS tabanlı çözüm, bir veya daha fazla ağ geçidi olanağını içerebilir, çünkü herhangi bir kuruluş, tümü ortak bir IBM COS arka ucunu kullanabilen bir gereksinimler karışımına sahip olabilir.

Not: Ayrıca, IBM Cloud Object Storage for Active Archiving kullanım senaryolarında dosyaları depolamak ve almak için eski uygulamalara SMB ve NFS protokolü arabirimi sağlayan COS ağ geçidi yazılımı da vardır. Arka uç IBM COS kovası uç noktasının şirket içinde veya IBM Public Cloud’da olabileceği bir sanal makine olarak şirket içinde devreye alınır.

Neden IBM Cloud Object Storage ?

• IBM COS, dosya tabanlı erişim için tek bir birleşik arka uç görevi görür. Eski depolama silosu yaklaşımını ortadan kaldırarak işletmeyi yönetim ve işletim maliyetlerinden kurtarır.
• IBM COS’a özgü, coğrafi olarak dağılmış silme kodlamalı veri koruması, verilerin birden çok sitede anında kullanılabilir olduğu anlamına gelir. Bu kullanılabilirlik, RAID ve çoğaltma yönetimini ve bu özelliğin gerektirdiği ekstra kapasiteyi ortadan kaldırır. Depolama ek yükü, yedeklemeler dahil 2 kattan azdır.
• Çözüme bağlı olarak, dosya erişimi için meta veriler, ağ geçidi cihazları arasında çoğaltılan bulutta saklanabilir veya aracı tabanlı çözümler durumunda kullanıcının yerel ana bilgisayarında depolanabilir. Bu yaklaşım, dosya tabanlı erişim için gerekli olan güvenlik yapılarını korur, yani uygulamaların yeniden yazılmasına gerek yoktur.
• İşletmelerin tek bir NAS çözümüne kilitlenmemesi için her iş yükü için en uygun çözüm kullanılabilir. Ölçek ekonomileri, tek bir depolama silosuna ayrılmış yüz ila binlerce disk iğine sahip büyük şirket içi NAS sistemlerinin devreye alınmasına bağlı NAS kafalarının aksine, temeldeki IBM COS katmanında elde edilir.

Kullanım Senaryoları 6 : İçerik Deposu

İçerik havuzu sistemleri, belgeler, resimler ve videolar gibi büyük dijital içerik kataloglarını yönetir. Bu sistemler, erişim kontrolü, belgeleri teslim etme ve teslim alma, dosya kilitleme ve dosya katmanlamayı içeren ancak bunlarla sınırlı olmayan kapsamlı arama ve dosya yönetimi işlevleri sağlamaları bakımından aktif arşivden farklıdır. Bu sistemler tipik olarak veri türlerinin bir karışımını depolar ve bu sistemlerdeki verileri günlük iş akışları için kullanabilen kullanıcılarına esnek hizmetler sağlamalıdır. Kilitleme özellikleri, kopyalanmış veya çatallanmış sürümlerin istenmeden oluşturulmamasını veya kullanıcılar eski dosyaları güncellenmiş bir sürüm üzerine kaydederek yanlışlıkla üzerine yazdığında verilerin kaybolmamasını sağlar. Daha eski bir içerik deposu sisteminde aşağıdaki koşullar mevcuttur:

• Dayanıklılık tipik olarak çoğaltma yoluyla sağlanır. Veri katmanlama, içerik havuzu sistemi tarafından yönetilebilir veya temeldeki veri korumasını gerçekleştiren aktif bir arşiv sisteminin üzerine yerleştirilebilir.
• İçerik havuzu sistemleri tipik olarak disk ve bant karışımından oluşturulur ve performansa duyarlı değildir. Bununla birlikte, verilerin bant gibi soğuk depodan geri çağrılması gerekiyorsa, uzun bekleme süreleri nedeniyle kullanıcı deneyimi ve üretkenliği tehlikeye girebilir.
• Olağanüstü durum kurtarma genellikle, kopyaların yükseltilmesi ve sıralamasının düşürülmesine yönelik geleneksel yüksek kullanılabilirlik (HA) prosedürlerini içerir ve yeni veriler orijinal sitelere kopyalanana kadar yeniden çalışma mümkün değildir.

Neden IBM Cloud Object Storage ?

• Geleneksel mimarilerdeki birçok sorunu çözebilen uygun maliyetli bir çözüm sunar.
• Çevrimdışı soğuk depolamanın kaldırılması, kullanıcıların verilere anında erişmesini sağlar. eski veriler için uzatılmış geri çağırma sürelerini beklemek.
• Sistem yöneticileri, veri eşlemeyi yönetmek için gereken kaynakları ortadan kaldırdığı için IBM COS’un coğrafi olarak dağınık yapısından yararlanır. Ayrıca, depo tarafından kullanılan veri deposunun karmaşık yük devretmesini de ortadan kaldırır.

Galiba bu sefer biraz uzun bir yazı oldu ama şuna emin olmamız lazım ki bir ürünü öğrenmek istiyorsak öncelikle bu ürünün nerelerde kullanıldığı ile ilgili senaryolara hakim olmamız gerekmektedir. Yani bir üründen konuşmak için öncelikle o ürünün kullanım senaryoları hakkında bilgi sahibi olmak şart.

Bir sonraki yazım IBM Cloud Object Storage’ın Planlama ve Boyutlandırması ile ilgili olacak ve sistemi nasıl şekillendireceğimizi konuşacağız.

IBM Storage ile ilgili diğer yazılarım için BURAYA tıklayın lütfen. IBM RedBook içerisindeki IBM Cloud Object Storage dökümanları içinde BURAYA tıklayın lütfen.

Yine IBM Cloud Object Storage içerisinde kullanılan teknolojileri sizlere anlatmaya çalışacağım.

Haydi başlayalım;

Dispersed Storage ( Dağınık Depolama ):

Bu sistem Erasure Coding denilen bir yapı kullanır. Erasure koding , L sembollü bir mesaj M sembollü daha uzun bir mesaja dönüştüren bir ileri hata düzeltme kodudur, öyle ki, orjinal mesaj M sembolün bir  alt kümesinden kurtarılabilir.

Dispersed storage network, dispersed storage nodelarından oluşur. İletişim doğası gereği özel ve güvenlidir. Tek bir storage üzerinde obje ile ilgili tüm içerik yoktur. Verinin tamamını almak için o obje için gerekli olan parçaların tamamının network içinde bulunması gerekir.

Faydaları

• Minimum admin eforu ile büyük ölçeklenebilirlik sağlar. Sistem Terabayt, Petabayt, Exabytes ve ötesinde veri ile çalışmak için tasarlanmıştır.
• %100 veri bütünlüğü korur. Verilere her zaman yer yerden erişilebilir. Veriler, eş zamanlı arızaları tolere edebilen bir mimariyle her zaman kullanılabilir.
• Birden çok sürücü veya sunucunun güvenliği ihlal edilse bile veri gizliliği sağlar. Hareket halindeki veriler ve durağan veriler, tanınmaz hale getirmek için şifrelenir.

Information Dispersal Algorithm ( IDA )

IBM COS sistemi, nesneleri slicerlara ağ bağlantıları yoluyla dağıtan dilimlere ayırmak için Information Dispersal Algorithm ( IDA ) kullanır. Orjinal veriler, bir dizi şifreleme, slicing ve erasure coding ile dönüştürülür.  Bu veri dilimleri IDA kullanılarak yüksek derecede başarısızlık sorunlarına göre Slicerlar üzerinde toplanır.
Dispersed Storagelar da,  verileri almak için yalnızca bir slices’ın alt dilimine ihtiyaç vardır. Dispersal storage sistemi, tek bir siteda ce birden çok siteda cihaz arızalarını tolere edebilir.

IBM COS’ta IDA, depolamanın genel kullanılabilirliğini ve güvenilirliğini tanımlayan paket düzeyinde üç parametre vardır;

Width : Bir veri segmentinin silme kodlamasıyla oluşturulan toplam dilim sayısı

Read Threshold : Bir dilimi okumak için gereken dilim sayısı

Write Threshold : Başarılı bir yazma işlemi için Slicestor nodelarına yazılması gereken sayı

IBM COS sistemi, slicesların yazılması ve okunmasını optimize etmek için SmartWrite ve SmartRead teknolojisini de kullanır, bu da daha yüksek verim ve verimlilik sağlar.

Güvenlik

• Veri güvenliği IBM COS sistemi üzerindeki SecureSlice sistemi ile sağlanır. SecureSlice, bilgilerin yanlızca tüm bilgiler biliniyor ise deşifre edilebildiği bir şifreleme yöntemi olan All-or-Nothing Transform (AONT) kullanır.
• Ağ güvenliği, IBM COS sistemi içinde akan tüm ağ trafiği AES ile TLS kullanılarak şifrelenmesi ile sağlanır. Slicestorlar, karmaşık bir güvenlik duvarı veya VPN kurulumu gerektirmeden herhangi bir yere yerleştirilebilir.
• Retention enabled bucket özelliği ile uyumluluk gereksinimleri sağlanır.

Access Method ( Erişim yöntemi )

Object-based access method: S3 uyumlu bir arayüze, HTTP / Rest API yoluyle erişilir. Basit PUT, GET, DELETE ve LIST komutları, uygulamaların verilere erişmesini sağlar.
Rest API erişiminin avantajları;

• Internet gecikmesini tölere eder.
• Programlanabilir depolama sağlar.
• Büyük miktarda veriye küresel erişim sağlar.

File-based access method: IBM COS, NAS, SMB, CIFS ve NFS protokolleri ile veri aktarımını destekler. Kullanıcılar ve depolama yöneticileri, standart dosya protokolleri üzerinden veri varlıklarını kolayca aktarabilir, erişebilir ve koruyabilir.

Yazılım Tanımlı Veri Depolama

Depolama tanımlı mimari çerçevesinde yazılım tanımlı depolama

Uçtan uca yazılım tanımlı bir storage sistemi ile beraber hız ve verimlilik yoluyla daha yüksek değer ve karlılık sağlayarak işletmelerin rekabet avantajı elde etmelerine yardımcı olabilecek optimize edilmiş BT altyazıları oluşturur ve uygular.

SDS karakteri ve faydaları;

• Düşük maliyetle beraber otomasyonu kolaylaştırır.
• Sistem yönetimini ve kontrolünü optimize ederek maliyetleri düşüren ve iş gereksinimlerini destekleyen etkili ve verimli kaynak kullanımına izin verir.
• Kaynak dağıtımı kolaydır.
• Mevcut kaynakların uygulama gereksinimlerine en uygun şekilde hizalanmasıyla performans ayarı yapar.
• Kapasite planlamayı kolaylaştırır ve büyük storage poollarını birden fazla servise dağıtılmasını sağlayabilir.
• Systems of Engagement (SoE) ve Systems of Record (SoR) kullanarak Systems of IBM Insight’ın gelişmiş uygulama konuşlandırmasını sağlar;
  • Cognitive : Cloud
  • Analytics : Mobile
  • Social
  • Security
• Basit mimari.
• Neredeyse sınırsız esnek veri ölçeklendirme.
• Blok, Dosya ve Obje data tiplerini destekler

IBM Cloud Object Storage ile Yazılım Tanımlı Veri Depolama

IBM COS sistemi, aynı zamanda donanıma duyarlı olan yazılım tanımlı bir sistemdir. IBM COS yazılımı, daha yeni modelleri ve donanım yeteneklerini destekler. NVMe ve daha büyük veya verimli depolama sunucuları ve disk sürücüleri gibi gelecekteki teknolojileri desteklemenin yolunu da hazırlar.

IBM Cloud Object Storage Kullanım Senaryolarına Giriş

• İlk kategori, geleneksel olarak dosya, blok veya teyp depolama sistemleri tarafından hizmet verilen bilinen ve olgunlaşmış iş yüklerini hedefler
• İkinci kategori, daha programatik olarak daha esnek olan ve verilere doğrudan erişme ve bunlardan içgörüler elde etme ve daha sonra bunları kullanıcılarar sunma olasılığı daha yüksek olan yeni uygulamalar ve çözümler olan ” Yeni ” iş yüklerini hedefler.

Bu yazı çok uzamasın diye, kullanım senaryolarının detaylarını bir sonraki yazıya saklıyorum.

Diğer IBM ile ilgili yazılarım için BURAYA

Podcast’ime ulaşmak, dinlemek ve abone olmak içinde BURAYA tıklıyoruz lütfen

Bu bir çeşit yazı dizisi olacak tabi bu not paylaşım olayı.

Öncelikle Blok storage nedir bir tanıma bakalım isterseniz;

Blok düzeyinde depolama olarak da adlandırılan blok depolama, veri dosyalarını Depolama Alanı Ağları (SAN’lar) veya bulut tabanlı depolama ortamları üzerinde depolamak için kullanılan bir teknolojidir. Geliştiriciler hızlı, verimli ve güvenilir veri aktarımı gerektiren bilgi işlem durumlarında blok depolamayı tercih ederler.

Blok depolama, verileri bloklara ayırmanın ardından bu blokları her biri benzersiz bir tanıtıcıya sahip ayrı parçalar halinde depolar. SAN, bu veri bloklarını en verimli olduğu konuma yerleştirir. Bu, SAN’ın bu blokları farklı sistemler genelinde depolayabileceği ve her bloğun farklı işletim sistemleriyle çalışacak şekilde yapılandırılabileceği (veya bölümlere ayrılabileceği) anlamına gelir.

Blok depolama, verileri kullanıcı ortamlarından ayrıştırarak bu verilerin çok sayıda ortama dağıtılmasını da sağlar. Böylece verilere giden çok sayıda yol oluşturulur ve kullanıcıların bu verileri hızla almalarına imkan tanınır. Bir kullanıcı veya uygulama bir blok depolama sisteminden veri istediğinde temelindeki depolama sistemi, veri bloklarını yeniden bir araya getirir ve verileri kullanıcıya veya uygulamaya sunar.

IBM olarak hazırlamış olduğumuz(ingilizce) süper bir video var Blok ile File yapılarını karşılaştıran, isterseniz aşağıdan bu videoyu izleyebilirsiniz.

Detaylı olarak özelliklerinden bahsetmeden önce bir giriş yapmış olalım ve bu obje storage’ın ne olduğu ile ilgili bir kaç genel tanım yapalım;

• Ölçeklenebilirlik, sürekli artan sayıda sınırlı kapasiteli depolama silosuna karşı tek bir depolama sistemi ve ad alanı sunar.
• Güvenlik özellikleri, güvenlik gereksinimlerinin karşılanmasına yardımcı olan çok çeşitli özellikleri içerir.
• Sistemin kullanılabilirlik ve güvenilirlik özellikleri, farklı kullanım durumları ve gereksinimlerine en iyi şekilde uyacak şekilde yapılandırılabilir.
• Yönetilebilirlik, depolama yöneticilerinin büyük depolama kapasitesini yönetmesine yardımcı olur.
• Yazılım tanımlı bir depolama çözümünün esnekliği, özel veya tescilli donanım.

Hazır tanımı verdiğime göre, bir de Obje storagelarla çalışmaya başladığımız zaman karşımıza çıkan terminolojiden biraz bahsetmek isterim.

Yukarıdaki resimde de görmüş olduğunuz gibi en küçük birleşen “Obje” ve objelerin birleşiminden veya içerisinde durdukları yer der isek, “Bucket” a ulaşıyoruz, Bucketlar ise “Storage pool“ların içerisinde bulunuyor ki onlarda “IBM Cloud Object Storage Sistemi” içinde bulunmaktadır.

Şimdi bunlar ile ilgili biraz daha detay verelim;

Object (Obje) :  Obje, IBM COS sistemine yüklenen kullanıcı verilerini ifade eder. Tipik olarak, bir dosya ve dosyayla birlikte depolanan nesne meta verileridir.

Bucket ( Kova ) : Bucket, verilerin depolanmak içn kullanılan mantıksal bir kapsamdır.

IBM Cloud Object Storage Manager Node : Sistem yapılandırması, depolama sağlama ve sistemin sağlığını ve performansını izleme gibi yönetim görevleri için kullanılan bir yönetim arabirimi sağlayan sistem birleşenidir. Bu node fiziksel bir cihaz, VMware sanal makinesi veya Docker konteynır olarak sistem içinde kullanılabilir.

IBM Cloud Object Storage Accesser Node : Yazma sırasında verileri şifreleyen ve kodlayan veya okunduğunda verilerin kodunu çözen ve şifresini çözen bir sistem birleşenidir. Verilerin dönüşümünü yöneten ve depolama arayüzlerini istemci uygulamalarına sunan bir birleşendir. Bir Accesser düğümü, bir IBM Slicestor cihazında fiziksel bir araç, VMware sanal makinesi, Docker konteyneri veya yerleşik bir Accesser olarak devreye alınabilir.

IBM Cloud Object Storage Slicestor Node : Verilerin depolanmasından sorumlu bir sistem bileşenidir. Yazma sırasında Accesser nodelardan veri alır ve okuma sırasında gerektiği gibi Accesser Nodelara veri döndürülür. Slicetor nodelar fiziksel olarak konuşlandırılır.

Device Set : Bir Device seti, bir grup Slicetor cihazı tarafından tanımlanır. Device setleri, bir veya daha fazla veri merkezine yayılabilir.

Storage Pool :  Storage Pool, birlikte bir veya daha fazla Bucket için fiziksel depolama kaynakları sağlayan bir veya daha fazla aygıt kümesinin mantıksal bir gruplamasıdır.

Access Pool : Access Pool, verilere erişmek için kullanılan bir veya daha fazla Accesser node’un mantıksal bir gruplamasıdır.

Bence yeterince bilgi bombardımanı oldu, o yüzden bu yazıya nokta koyma zamanı geldiğine inanıyorum.

Diğer IBM ile ilgili yazılarım için BURAYA

Podcast’ime ulaşmak, dinlemek ve abone olmak içinde BURAYA tıklıyoruz lütfen.