Bugün Unity/Unity XT depolama sistemlerinde uygulanan ilginç bir teknolojiden bahsedeceğiz - FAST VP. Unity'yi ilk kez duyuyorsanız yazının sonundaki bağlantıdan sistem özelliklerine göz atabilirsiniz. Bir yıldan fazla bir süre Dell EMC proje ekibinde FAST Başkan Yardımcısı olarak çalıştım. Bugün bu teknolojiden daha detaylı bahsetmek ve uygulanmasına ilişkin bazı detayları ortaya çıkarmak istiyorum. Elbette sadece açığa çıkmasına izin verilenler. Verimli veri depolama sorunlarıyla ilgileniyorsanız veya belgeleri tam olarak anlamadıysanız, bu makale kesinlikle yararlı ve ilginç olacaktır.
Malzemede nelerin olmayacağını hemen söyleyeceğim. Rakip arama ve onlarla karşılaştırma yapılmayacaktır. Ayrıca açık kaynaklı benzer teknolojilerden bahsetmeyi de düşünmüyorum çünkü meraklı okuyucu bunları zaten biliyor. Ve elbette hiçbir şeyin reklamını yapmayacağım.
Depolama Katmanlaması. FAST VP'nin amaç ve hedefleri
FAST VP, Sanal Havuz için Tam Otomatik Depolama Katmanlaması anlamına gelir. Biraz zor? Sorun değil, şimdi çözeceğiz. Katmanlama, bu verilerin depolandığı çeşitli düzeylerin (katmanların) bulunduğu veri depolamayı düzenlemenin bir yoludur. Her birinin kendine has özellikleri vardır. En önemlisi: bir birim bilgiyi depolamanın performansı, hacmi ve fiyatı. Elbette aralarında bir ilişki var.
Katmanlamanın önemli bir özelliği, verilere erişimin, mevcut durumda bulunduğu depolama düzeyine bakılmaksızın eşit şekilde sağlanması ve havuzun boyutunun, içinde yer alan kaynakların boyutlarının toplamına eşit olmasıdır. Önbellek ile arasındaki farklar burada yatmaktadır: önbelleğin boyutu, kaynağın toplam hacmine eklenmez (bu durumda havuz) ve önbellek verileri, ana medya verilerinin bir kısmını çoğaltır (veya eğer önbellekten veri henüz yazılmadı). Ayrıca verilerin seviyelere göre dağılımı da kullanıcıdan gizlenir. Yani, her düzeyde hangi verilerin bulunduğunu tam olarak göremiyor, ancak bunu politikalar belirleyerek dolaylı olarak etkileyebilir (bunlar hakkında daha sonra daha fazla bilgi vereceğiz).
Şimdi Unity'de depolama katmanlamanın uygulanmasının özelliklerine bakalım. Birliğin 3 seviyesi veya kademesi vardır:
- Olağanüstü performans (SSD'ler)
- Performans (SAS HDD 10k/15k RPM)
- Kapasite (NL-SAS HDD 7200 RPM)
Performans ve fiyata göre azalan sırada sunulurlar. Olağanüstü performans yalnızca katı hal sürücülerini (SSD'ler) içerir. Diğer iki katman, dönüş hızı ve buna bağlı olarak performans açısından farklılık gösteren manyetik disk sürücülerini içerir.
Aynı seviyedeki ve aynı boyuttaki depolama ortamları bir RAID dizisinde birleştirilir ve bir RAID grubu (RAID grubu, RG olarak kısaltılır) oluşturulur; Mevcut ve önerilen RAID seviyelerini resmi belgelerde okuyabilirsiniz. Depolama havuzları, bir veya daha fazla düzeydeki RAID gruplarından oluşturulur ve boş alan daha sonra dağıtılır. Ve havuzdan dosya sistemleri ve LUN'lar için alan ayrılmıştır.
Neden Katmanlamaya ihtiyacım var?
Kısaca ve özet olarak: Minimum kaynak kullanarak daha büyük sonuçlar elde etmek. Daha spesifik olarak, sonuç genellikle bir dizi depolama sistemi özelliği (hız ve erişim süresi, depolama maliyeti ve diğerleri) olarak anlaşılır. Minimum kaynak, en az harcama anlamına gelir: para, enerji vb. FAST VP, Unity/Unity XT depolama sistemlerinde verileri farklı düzeylerde yeniden dağıtmaya yönelik mekanizmalar uygular. Bana inanıyorsan sonraki paragrafı atlayabilirsin. Geri kalanı için size biraz daha anlatacağım.
Verilerin depolama katmanları arasında doğru şekilde dağıtılması, nadiren kullanılan bazı bilgilere erişim hızından ödün vererek genel depolama maliyetinden tasarruf etmenize ve sık kullanılan verileri daha hızlı ortama taşıyarak performansı artırmanıza olanak tanır. Burada birisi, katmanlama olmadan bile normal bir yöneticinin hangi verileri nereye yerleştireceğini, görevi için bir depolama sisteminin arzu edilen özelliklerinin neler olduğunu vb. bildiğini iddia edebilir. Bu şüphesiz doğrudur, ancak verileri manuel olarak dağıtmanın dezavantajları vardır:
- yöneticinin zamanını ve dikkatini gerektirir;
- Depolama kaynaklarını değişen koşullara uyacak şekilde "yeniden çizmek" her zaman mümkün değildir;
- önemli bir avantaj ortadan kalkıyor: farklı depolama düzeylerinde bulunan kaynaklara birleşik erişim.
Depolama yöneticilerinin iş güvenliği konusunda daha az endişelenmesini sağlamak için burada da yetkin kaynak planlamasının gerekli olduğunu ekleyeceğim. Artık kademelendirme görevleri kısaca özetlendiğine göre, FAST VP'den neler bekleyebileceğinize bir göz atalım. Artık tanımlamaya dönme zamanı geldi. İlk iki kelime - Tam Otomatik - kelimenin tam anlamıyla "tam otomatik" olarak tercüme edilir ve seviyeler arasındaki dağıtımın otomatik olarak gerçekleştiği anlamına gelir. Sanal Havuz, farklı depolama düzeylerinden kaynakları içeren bir veri havuzudur. Şuna benziyor:
İleriye baktığımda, FAST VP'nin verileri birkaç havuz arasında değil, yalnızca tek bir havuzda taşıdığını söyleyeceğim.
FAST VP tarafından çözülen sorunlar
Önce soyut olarak konuşalım. Bir havuzumuz ve bu havuzdaki verileri yeniden dağıtabilecek bazı mekanizmalarımız var. Amacımızın maksimum üretkenliğe ulaşmak olduğunu hatırlayarak kendimize şu soruyu soralım: Bunu hangi yollarla başarabiliriz? Bunlardan birkaçı olabilir ve burada FAST VP'nin kullanıcıya sunabileceği bir şey var çünkü teknoloji depolama katmanlamasından daha fazlasıdır. FAST VP'nin havuz performansını artırmasının bazı yolları şunlardır:
- Verilerin farklı disk türleri ve düzeylere dağılımı
- Verileri aynı türdeki diskler arasında dağıtma
- Havuzu genişletirken veri dağıtımı
Bu görevlerin nasıl çözüldüğüne bakmadan önce FAST VP'nin nasıl çalıştığına dair bazı gerekli gerçekleri bilmemiz gerekiyor. FAST VP, belirli bir boyuttaki bloklarla çalışır - 256 megabayt. Bu, taşınabilecek en küçük bitişik veri "yığınıdır". Belgelerde buna şöyle diyorlar: dilim. FAST VP açısından bakıldığında, tüm RAID grupları bu tür "parçalardan" oluşur. Buna göre bu tür veri blokları için tüm G/Ç istatistikleri toplanır. Bu blok boyutu neden seçildi ve küçültülecek mi? Blok oldukça büyüktür, ancak bu, verilerin ayrıntı düzeyi (daha küçük blok boyutu daha doğru dağıtım anlamına gelir) ile mevcut bilgi işlem kaynakları arasında bir uzlaşmadır: RAM ve çok sayıda blok üzerindeki mevcut katı sınırlamalar göz önüne alındığında, istatistik verileri yer kaplayabilir çok fazla olursa hesaplama sayısı da orantılı olarak artacaktır.
FAST VP'nin verileri havuza nasıl tahsis ettiği. Politikacılar
FAST VP'nin etkin olduğu bir havuza veri yerleşimini kontrol etmek için aşağıdaki politikalar mevcuttur:
- Mevcut En Yüksek Seviye
- Otomatik Katman
- Yüksek Başlat, ardından Otomatik Katman (varsayılan)
- Mevcut En Düşük Seviye
Hem ilk blok tahsisini (ilk olarak yazılan veriler) hem de sonraki yeniden tahsisi etkilerler. Veriler zaten disklerde bulunduğunda, yeniden dağıtım bir programa göre veya manuel olarak başlatılacaktır.
Mevcut En Yüksek Seviye, en yüksek performanslı seviyeye yeni bir blok yerleştirmeye çalışır. Üzerinde yeterli alan yoksa, bir sonraki en verimli seviyeye yerleştirilir, ancak daha sonra veriler daha verimli bir seviyeye taşınabilir (boşluk varsa veya diğer veriler değiştirilerek). Otomatik Katman, kullanılabilir alan miktarına bağlı olarak yeni verileri farklı düzeylere yerleştirir ve talebe ve boş alana göre yeniden dağıtılır. Yüksekten Başla, ardından Otomatik Katmanlama varsayılan politikadır ve ayrıca önerilir. Başlangıçta yerleştirildiğinde Mevcut En Yüksek Katman olarak çalışır ve ardından veriler, kullanım istatistiklerine bağlı olarak taşınır. Mevcut En Düşük Katman politikası, verileri en az üretken katmana yerleştirmeyi amaçlar.
Veri aktarımı, depolama sisteminin yararlı çalışmasına müdahale etmemek için düşük öncelik ile gerçekleşir, ancak önceliği değiştiren bir "Veri yeniden konumlandırma hızı" ayarı vardır. Burada bir tuhaflık var: tüm veri blokları aynı yeniden dağıtım sırasına sahip değil. Örneğin, meta veri olarak işaretlenen bloklar önce daha hızlı bir düzeye taşınacaktır. Meta veriler, tabiri caizse "verilerle ilgili verilerdir", kullanıcı verileri olmayan ancak açıklamasını saklayan bazı ek bilgilerdir. Örneğin, dosya sistemindeki belirli bir dosyanın hangi blokta bulunduğuna dair bilgiler. Bu, verilere erişim hızının meta verilere erişim hızına bağlı olduğu anlamına gelir. Meta verilerin boyutunun genellikle çok daha küçük olduğu göz önüne alındığında, onu daha yüksek performanslı disklere taşımanın faydalarının daha büyük olması beklenir.
Fast VP'nin çalışmalarında kullandığı kriterler
Her blok için ana kriter, kabaca, bir veri parçasının okuma ve yazma işlemlerinin sayısına bağlı olan veri "talebinin" karakteristiğidir. Bu özelliğe “Sıcaklık” diyoruz. Talep edilmeyen verilerden “daha sıcak” olan talep edilen (sıcak) veriler vardır. Varsayılan olarak bir saatlik aralıklarla periyodik olarak hesaplanır.
Sıcaklık hesaplama fonksiyonu aşağıdaki özelliklere sahiptir:
- G/Ç'nin yokluğunda veriler zamanla "soğur".
- Zamanla az çok eşit yük altında sıcaklık önce artar, sonra belirli bir aralıkta sabitlenir.
Daha sonra yukarıda açıklanan politikalar ve her katmandaki boş alan dikkate alınır. Netlik sağlamak için belgelerden bir resim sunacağım. Burada kırmızı, sarı ve mavi renkler sırasıyla yüksek, orta ve düşük sıcaklığa sahip blokları gösteriyor.
Ama görevlere geri dönelim. Böylece FAST VP sorunlarını çözmek için neler yapıldığını analiz etmeye başlayabiliriz.
A. Verilerin farklı disk türleri ve düzeylere dağılımı
Aslında FAST VP'nin asıl görevi budur. Geriye kalanlar bir anlamda onun türevleridir. Seçilen politikaya bağlı olarak veriler farklı depolama düzeylerine dağıtılacaktır. Öncelikle yerleştirme politikası, ardından blok sıcaklığı ve RAID gruplarının boyutu/hızı dikkate alınır.
Mevcut En Yüksek/En Düşük Katman politikaları için her şey oldukça basittir. Diğer ikisi için de durum böyle. Veriler, RAID gruplarının boyutu ve performansı dikkate alınarak farklı düzeylere dağıtılır: böylece blokların toplam "sıcaklığının" her RAID grubunun "koşullu maksimum performansına" oranı yaklaşık olarak aynıdır. Böylece yük az çok eşit olarak dağıtılır. Daha fazla talep gören veri hızlı ortama, nadiren kullanılan veriler ise daha yavaş ortama taşınır. İdeal olarak dağılım şöyle görünmelidir:
B. Verilerin aynı türdeki diskler arasında dağıtımı
Unutmayın, başlangıçta bu depolama ortamını yazdım. bir veya daha fazla seviyeler tek bir havuzda birleştirildi mi? Tek seviye söz konusu olduğunda FAST VP'nin de yapması gereken işler vardır. Her düzeyde maksimum performansa ulaşmak için verilerin diskler arasında eşit şekilde dağıtılması önerilir. Bu (teoride) maksimum IOPS miktarını elde etmenize olanak sağlayacaktır. Bir RAID grubu içindeki verilerin diskler arasında eşit şekilde dağıtıldığı düşünülebilir ancak bu, RAID grupları arasında her zaman geçerli değildir. Dengesizlik durumunda FAST VP, verileri hacimlerine ve "koşullu performansa" (sayısal olarak) orantılı olarak RAID grupları arasında taşıyacaktır. Açıklık sağlamak için üç RAID grubu arasındaki yeniden dengeleme şemasını göstereceğim:
B. Havuzu genişletirken veri dağıtımı
Bu görev öncekinin özel bir durumudur ve havuza bir RAID grubu eklendiğinde gerçekleştirilir. Yeni eklenen RAID grubunun boşta kalmamasını sağlamak için verilerin bir kısmı ona aktarılacak, bu da yükün tüm RAID gruplarına yeniden dağıtılacağı anlamına geliyor.
SSD Aşınma Dengeleme
FAST VP, aşınma dengelemeyi kullanarak bir SSD'nin ömrünü uzatabilir, ancak bu özellik doğrudan Depolama Katmanlaması ile ilgili değildir. Sıcaklık verileri zaten mevcut olduğundan, yazma işlemlerinin sayısı da dikkate alındığından ve veri bloklarının nasıl taşınacağını bildiğimizden, FAST VP'nin bu sorunu çözmesi mantıklı olacaktır.
Bir RAID grubundaki giriş sayısı diğerindeki giriş sayısını önemli ölçüde aşarsa FAST VP, verileri yazma işlemlerinin sayısına göre yeniden dağıtacaktır. Bu, bir yandan yükü hafifletir ve bazı disklerin kaynağından tasarruf sağlar, diğer yandan daha az yüklü olanların "işini" artırarak genel performansı artırır.
Bu şekilde FAST VP, Depolama Katmanlamanın geleneksel zorluklarını üstlenir ve bundan biraz daha fazlasını yapar. Tüm bunlar, verileri Unity depolama sisteminde oldukça verimli bir şekilde saklamanıza olanak tanır.
Birkaç ipucu
- Dokümantasyonu okumayı ihmal etmeyin. En iyi uygulamalar var ve oldukça iyi çalışıyorlar. Onları takip ederseniz, kural olarak ciddi bir sorun ortaya çıkmaz. Tavsiyenin geri kalanı temelde bunları tekrarlıyor veya tamamlıyor.
- FAST VP'yi yapılandırıp etkinleştirdiyseniz, onu etkin bırakmak daha iyidir. Verileri kendisine ayrılan sürede ve azar azar yılda bir kez dağıtmasına ve diğer görevlerin performansı üzerinde ciddi bir etkisi olmasına izin verin. Bu gibi durumlarda verilerin yeniden dağıtımı uzun zaman alabilir.
- Bir yer değiştirme penceresi seçerken dikkatli olun. Bu açık olsa da Unity'nin en az yükleneceği zamanı seçmeye çalışın ve yeterli bir süre ayırmaya çalışın.
- Depolama sisteminizi genişletmeyi planlayın ve bunu zamanında yapın. Bu, FAST VP için de önemli olan genel bir öneridir. Boş alan miktarı çok azsa veri hareketi yavaşlayacak veya imkansız hale gelecektir. Özellikle 2. noktayı ihmal ettiyseniz.
- FAST VP etkinken bir havuzu genişletirken en yavaş disklerle başlamamalısınız. Yani ya planlanmış tüm RAID gruplarını aynı anda ekliyoruz ya da önce en hızlı diskleri ekliyoruz. Bu durumda verileri yeni "hızlı" disklere yeniden dağıtmak havuzun genel hızını artıracaktır. Aksi takdirde “yavaş” disklerle başlamak çok hoş olmayan bir duruma yol açabilir. İlk olarak veriler yeni, nispeten yavaş disklere aktarılacak ve daha sonra daha hızlı olanlar eklendiğinde ters yönde aktarılacaktır. Burada farklı FAST VP politikalarıyla ilgili nüanslar var, ancak genel olarak benzer bir durum mümkün.
Bu ürüne bakıyorsanız Unity VSA sanal cihazını indirerek Unity'yi ücretsiz deneyebilirsiniz.
Materyalin sonunda birkaç yararlı bağlantı paylaşıyorum:
- Sayfa
- – fonksiyonun kısa açıklaması
- , pdf formatı
Sonuç
Çok şey yazmak isterdim ama tüm ayrıntıların okuyucunun ilgisini çekmeyeceğini anlıyorum. Örneğin, FAST VP'nin veri aktarımına ilişkin kararları alırken kullandığı kriterler, I/O istatistiklerini analiz etme süreçleri hakkında daha detaylı konuşabilirsiniz. Ayrıca etkileşim konusu ve bu ayrı bir makaleyi hak ediyor. Hatta bu teknolojinin gelişimini hayal bile edebilirsiniz. Umarım sıkıcı olmamıştır ve sizi sıkmamışımdır. Tekrar görüşürüz!
Kaynak: habr.com