Flash depolama öncüsü Pure Storage, yakın zamanda dizilerindeki depolama kapasitesini, herhangi bir uygulamanın ihtiyaç duyduğu şekilde kolayca sağlanmasına olanak tanıyan depolama sınıfları aracılığıyla kullanılabilir hale getirmek için Fusion kontrol düzlemini yükselteceğini duyurdu.
Bu durum, depolama işlemini daha basit hale getirerek ve çok sayıda uygulama tarafından çeşitli ortamlarda ve çok sayıda sunucuda daha kolay tüketilebilir hale getirerek potansiyel olarak birçok avantaj sağlar.
Kubernetes, uygulamalara tanımlanmış profillerle kalıcı depolama sağlamak için uzun zamandır depolama sınıfları konseptini kullanıyor. Ancak bu, Kubernetes’in en üstten en alta kontrol ettiği konteynerleştirilmiş ortamlarda oluyor.
Peki, Pure’un Fusion kontrol düzlemi için depolama sınıfları heterojen veri merkezi ortamlarında nasıl çalışacak?
Haziran ortasında Las Vegas’ta düzenlenen Pure’un Accelerate etkinliğinde, Pure Storage kurucusu ve baş vizyoner yöneticisi John “Coz” Colgrove ile bir araya gelerek kendisine bu soruyu sorduk.
Fusion için duyurulan yeni işlevselliği nasıl özetlersiniz?
John “Coz” Colgrove:Fusion’ın amacı, dizi filonuzu bir hizmet teklifi olarak çalıştırmanıza, az sayıda depolama sınıfı tanımlamanıza ve böylece ortamınızda çok daha fazla tutarlılık elde etmenize olanak sağlamaktır.
Tipik bir müşteri birkaç dizi satın alır. Gelecek yıl, birkaç dizi daha satın alır ve sonraki yıl daha fazlasını satın alır. Belki de gelecek yıl, daha öncekilerden birkaçını devre dışı bırakır ve birkaç tane daha satın alır.
Bir sürü farklı zamanda satın aldıkları bir filoları var. Farklı dizi sınıfları, belki aynı sınıfın farklı nesilleri var. Yani, heterojen bir filoları var ve onu tek tip kullanım elde etmek için yönetmekte zorluk çekiyorlar.
Çünkü, elbette, bu şeylerin performans seviyeleri ve kapasiteleri farklıdır. Bunun diğerinde olmayan üç özelliği vardır. Bunun iki farklı özelliği vardır. Ve böylece, veri merkezinizde 27 farklı depolama türünden oluşan bir karmaşaya sahip olursunuz.
Şimdi bir değişiklik yapmaya çalışıyorsunuz. Örneğin, bu yeni güvenlik özelliğini uygulamak istiyorsam, bunu planlamak ve yapmak çok daha zordur çünkü tüm bu farklı depolama türleri, onu nasıl uygulayacağınızı bulmanız gerektiği anlamına gelir.
Fusion’ın size yapması gereken şey, depolama sınıflarını niteliklerle tanımlayan az sayıda kişiye sahip olmaktır. Daha sonra kullanıcılarınızın bunu API sağlama yoluyla yapmasını sağlayabilirsiniz veya yine de BT yöneticilerinin bunu, kullanıcının “10TB’a ihtiyacım var” diyerek bir bilet açmasıyla yapmasını sağlayabilirsiniz ve onlar da bunu çözerler.
Tüm bu dizilere gidip hangisinin kapasiteye sahip olduğunu, hangisinin yeterli performansa sahip olduğunu, hangisinin doğru türde ayara sahip olduğunu bulmaları gerekmesi yerine, Fusion bunların hepsini anlayacak ve bunları sınıflandıracak, şöyle ki: işte A sınıfı depolama alanım, işte B sınıfı depolama alanım, işte C sınıfı depolama alanım.
Ve her organizasyona şunu söylerdim, üç veya belki dörtten fazla sınıfınız olmamalı. Bu şekilde, veri merkezi hizmetleriniz hakkında akıl yürütebilir ve bunları tutarlı bir şekilde taşıyabilirsiniz. Tüm bunlar, insanların ortamlarından çok daha fazla yararlanmalarını sağlamalıdır.
Çünkü bir diğer sorununuz da şu ki bu dizileri satın alıyorsunuz ve örneğin finans departmanı bir diziye sahip oluyor ve uygulamaları dizide yer alıyor. Ve eğer onu doldurmuyorlarsa, başka kimsenin de dizide yer almasını istemiyorlar, değil mi? Ondan kurtulmanız gerekiyor. Bulut bunu yapmıyor. Hiçbir anlamı yok.
20, 30, 50, 100 diziye sahip olan ve bunların %40, %50, %30’unun kullanıldığını görüyoruz. Bunları %70 veya %80’e çıkararak başlamak istiyorum ve Fusion’ın yapmak istediği de bu.
Fusion projesine başladığımızda, greenfield dağıtımlarının peşine düştük. Yapılması en kolay şeydi ve eski ortamlar hakkında endişelenmek zorunda değildik. Bu bir hataydı. Yeni Fusion’ın yaptığı şey, brownfield dağıtımlarının peşine düşmek. Zaten filoları olan kişiler artık gidip Fusion’ı dağıtabilir ve özünde mevcut yapılandırmalarını özümseyip Fusion’ı kullanarak yeni şeyler dağıtmaya başlayabilir.
Sonraki aşama, Fusion’ın tüm bu dizilerde sorunsuz bir şekilde yeniden dengelenmesini sağlayacak. Fusion, yük dengeleme şeyleri önermeye başlayacak.
Bunlardan bazılarını gördünüz [Pure’s AI] Copilot. Şu anda bu yaz bir teknoloji önizlemesi, ancak yayınlandığında Fusion ile birlikte gelecek. Bu filo içgörülerini edinmenize yardımcı olacak. Uzman olmayan kullanıcıların filo hakkında derin içgörüler edinmesine ve çok daha stratejik kararlar almasına yardımcı olacak
Pure, Fusion’ı eski ortamlarda çalıştırmak için hangi mühendislik engellerini aşmak zorunda kaldı?
Çünkü: En önemli şey, oradaki her birimin, her nesnenin Fusion ile yapılandırılmış olması, dolayısıyla Fusion’ın her şey hakkında bilgi sahibi olmasıydı.
Merkezi Fusion veritabanı tüm bu bilgilere sahip olabilir ve bunların hepsinin bu tanımlanmış depolama sınıflarından birine uyduğunu söyleyebilir. Brownfield’daki zor kısım, mevcut tüm yapılandırmaları alacağımızı ve bunları alıp bir Fusion yapılandırmasına dönüştüreceğimizi söylemekti.
Fusion, bir site gibi şeylerin bir kavramına sahiptir. Bazı bulut kavramlarına çok benzer. Mevcut yapılandırmada mevcut olan bir site bilgisi yoktur.
“Mevcut yapılandırmadaki her şeyi içe aktaracağız ve bu varsayılan çalışma alanına çekeceğiz” gibi kararlar almanız gerekiyordu.
Fusion’ın bir diğer konsepti, depolama sınıflarınızla kontrol ettiğiniz bir çalışma alanınız olabileceği ve benim de benimkiyle kontrol ettiğim bir çalışma alanım olabileceği fikridir. Yani, tüm mevcut yapılandırmayı alması, içeri çekmesi ve tüm bu şeyler için varsayılanlar oluşturması gerekiyordu. Daha önce olmayan tüm konseptler.
Kubernetes’te kalıcı birimleriniz ve depolama sınıflarınız var ve uygulamaların depolama sınıfları ve kalıcı birimler üzerinde hak iddiaları var. Bunun Kubernetes’te nasıl çalıştığını görmek kolaydır, çünkü Kubernetes bu ilişkileri yöneten aracıdır. Fusion’da bunun benzeri nedir veya bir benzeri var mıdır? Nasıl çalışır?
Çünkü: Hayır, çok büyük bir benzerlik var, bahsettiğim şey de buydu, siteler, çalışma alanları ve bunun gibi şeyler.
Bulut, Kubernetes’ten bile önce, bir site veya bir bölge kavramını, sanırım buna bir bölge içindeki kullanılabilirlik bölgesi diyebilirsiniz, insanların çalışma biçimine bu tür kavramları getirdi. Ve Kubernetes’in benzer bir kavram seti var ve bunlar arasında bazı ufak farklar var, ancak Fusion’da aynı şeyleri benimsedik; siteler, kullanılabilirlik bölgeleri ve bu tür şeyler.
Çünkü yapmaya çalıştığımız şey, şirket içinde çalıştırabileceğiniz veya şirket içinde çalıştırıp Pure Cloud Block Store’unuza ve bulut kaynaklarınıza genişletebileceğiniz bulut benzeri bir hizmet teklifi oluşturmak.
Fusion, uygulamada kalıcı bir hacim talebinin eşdeğerini benzer şekilde sağlıyor mu?
Çünkü: Kalıcı birim iddiası daha çok bir kapsayıcı şeydir, bu yüzden daha çok Portworx olurdu. Ancak benzetme normalde bir dosya sisteminiz veya bir biriminiz olduğunda, bir dizi dışa aktarma kuralı altında dışa aktarılır, bir dosya sistemi durumunda veya bir ana bilgisayara, Fiber Kanala, iSCSI’ye, NVMe’ye vb. bağlıyken, ancak bu ana bilgisayar bağlantınız vardır.
Ana bilgisayar bağlantısının kalıcı bir rezervasyon veya kalıcı bir ilişkiye eşdeğer olduğunu iddia edebilirsiniz. Çünkü veri merkezinizi her kapatıp yeniden başlattığınızda geri gelir.
Kubernetes’te olanlara benzer şekilde, çok sayıda eski uygulamanın bulunduğu karmaşık bir ortamınız varsa, bu uygulamalar depolama sınıflarına ilişkin hak iddialarını nasıl ortaya koyar?
Çünkü: Konteyner tabanlı uygulamalarınızı yönetmek için hala Portworx veya benzeri bir şey kullandığınızı söyleyebilirim.
Peki ya konteyner tabanlı olmayan uygulamalar?
Çünkü: Konteyner tabanlı olmayan uygulamalar, örneğin, beş birimden oluşan bir veritabanına sahiptir. Bu birimleri bu ana bilgisayara bağlamak için dizi yapılandırmasında kalıcı bir bağlantı kurulumu olacaktır.
Fusion’ın farklı yaptığı şeylerden biri de – dengeleme konusunda söylediklerime geri dönersek – filodan en iyi şekilde yararlanmak için yüksek performanslı bir uygulamayı alıp hepsini tek bir diziye koymamalısınız.
Yüksek performanslı uygulamanızı bir dizi grubuna dağıtmalısınız ve düşük performanslı uygulamalarınızı da bu dizilere dağıtmalısınız, böylece hem yoğunluk hem de kapasite açısından eşit kullanım elde edersiniz.
Eskiden, Fusion öncesinde, yeni bir veritabanı oluşturmak isterseniz, yapacağınız şey buydu. Örneğin, “Bir günlük birimine, bir geçici birime ve üç veri birimine ihtiyacım var” derdiniz ve normalde kapasite ve performansa sahip bir dizi bulur, bu beş birimi dizide oluştururdunuz – ve belki de bunların hepsini uygulamanın her diğer örneğiyle mükemmel bir şekilde tutarlı bir şekilde oluşturmazdınız – ve sonra bu diziden bu veritabanına karşı çalıştıracağımız ana bilgisayarlara bir bağlantı kurardınız.
Fusion dünyasında, “Bu uygulama için bu beş cildi istiyorum.” diyeceksiniz. Uygulama için bir şablonunuz olabilir. Ya da, “Bu beş cildi istiyorum ve bu dört cildin A sınıfı olmasını istiyorum ve bu taslak cildin C sınıfı olmasını istiyorum çünkü aynı şekilde yedeklemeyi umursamıyorum.” diyeceksiniz.
Fusion gidip bunları potansiyel olarak beş farklı diziye koyacak çünkü Fusion filonuzdaki alanı bulacak ve ardından hacmi örnekleyecek ve bağlantıyı örnekleyecek. Ve böylece bunu filonuzu çok daha iyi kullanmanızı ve çok daha fazla tutarlılık sağlamanızı sağlayacak şekilde yapmanıza olanak tanıyacak. Bence bunlar en büyük iki fayda.
Bir değişiklik yapmak istediğinizde ve “Fidye yazılımlarına karşı daha iyi koruma sağlamam gerek” veya “Yedeklememde daha iyi koruma sağlamam gerek” dediğinizde her zaman geri dönerim. Ortamınız hakkında daha basit olduğu için akıl yürütebildiğinizde daha iyi bir karar verirsiniz.
Ve sonra, tabii ki, bunu sadece “Sınıf A depolama tanımını her sekiz saatte bir yerine her dört saatte bir yedeklenecek şekilde değiştirmek ve bunu tüm filoda yaptırmak istiyorum” diyerek uygulayabilirsiniz. Bu, insanların bugün sahip olmadığı bir güçtür.