Kahveler hazır mı? Hazırsa haydi kaldığımız yerden devam edelim.

Bugünkü yazımda sistemde oluşabilecek hata ve arızalara karşı vSAN’ın savunma gardını konuşacağız.

vSAN Storage Policy

vSAN object based bir storage olduğu için objelerin koruması yapılır ve objelerin korumasının yapılabilmesi için de bizim o objelerin yapılacağı politikaları hazırlamamız gerekir. ( Ne çok obje dedim :D)

vSAN’da storage policy base management imkanı vardır. İsterseniz varsayılan politikaları kullanır, isterseniz de ihtiyacınıza göre politika oluşturabilirsiniz. vSAN’ın defaultta bir policysi bulunur.

Object Repair Timer

Objeler komponentlerden oluşur. Komponentler gün gelir arızalanabilir. Sistemde hatayı görebilmek adına vSAN’ın da bir işlemde bulunması gerekebilir. Amaç hata anında, bir disk arızasında sistem recovery senaryosunu devreye alsın olmalıdır. Peki komponentler hangi durumlarda olabilir?

Absent: Hata/arızadan dolayı oluşur. Geri dönüşünün olduğuna inandığı belirsizlikleri temsil eder diyebiliriz.

Active-State: Aynı vSAN objesini oluşturan komponentler birbirleri arasında sync yapamadığında karşımıza çıkar.

Degrated: Sistemde büyük bir arıza gibi algılanabilir. Aslında bir arızadan kaynaklı alınan uyarıdır. Mesela ESXI sunuculardan birini reboot edersem componentler degrated duruma düşer. Beklemediği anda gelen sürprizlere tepkisidir.

vSAN bir hata tespit ettiğinde onu onarmak için belli bir süre bekler. Bu süreye “object repair timer” denir. Bu süre defaultta 60 dkka olarak ayarlanmıştır. Dilerseniz bu süreyi değiştirebilirsiniz.

Host Isolation Response

Eğerki bir sunucu clusterın diğer üyelerinden cevap alamıyor ve dolayısıyla da default gatewayine gidecek duruma geliyorsa, ve gatewayden de cevap alamıyorsa “Host Isolation Response”‘u uygulayacaktır. vSAN’daki yapıda gateway vSAN networkü olacaktır.

Burada 3 seçenekten birini cevap olarak ayarlamanız mümkündür. Disabled seçerseniz default gatewayine ping atamadın beklemeye devam et demiş olursunuz. Host fail durumda ama üzerindeki vmler çalışmaya devam eder. Power off and restart VMs’i seçerseniz fişini çeker gibi düşünelim, diğeri de makine içinden kapatma talimatı vermektir. İhtiyacınıza göre tercih edebilirsiniz.

Fault Domain

Amacı veriyi domainler arasında bölmek, yani sistemizdeki sunucuları gruplamaktır. Bir örnek ile açıklayacak olursak aşağıdaki şekilde bir vSAN Cluster yapımız olsun. 4 sunucumuz var ve bunlar 2 farklı kabinde olsun. Kabinler arası da bağlantı olduğunu düşünelim. Bir sanal makinemi 2 farklı kabinette oluşturulmus vSAN’a atarsam 3 ihtimalle çalışabilir. Kabin 1’de çalışabilir, kabin 2 ‘de çalışabilir ya da verileri kabin ve kabin 2’ye dağılabilir. Ama biz isteriz ki mirror yapımız olsun, kabin 1’e bir şey olma ihtimalinde verim diğer kabinde de olsun. Peki bunu yapabilr miyiz? Normal şartlarda yapamayız. Amaaa vSAN’ın fault domain özelliği ile bunu yapmak mümkün. Eğer sanal makinemin 1 komponentinin 1-2 hostunda, diğer komponentimin de 3-4 hostlarında durmasını istiyorsak fault domaini kullanabiliriz.

vSAN cluster‘ında bulunan her host dolaylı olarak fault domain kabul edilir. vSAN, tüm vSAN nesnelerinin bileşenlerini, Number of Failures to Tolerate kuralına göre otomatik olarak cluster’daki Fault Domain’lere dağıtır.

NumberOfFailuresToTolerate = 1 olan bir sanal makineyi deploy ederken 2n+1 kuralına uymalıyız. Yani burada 1 arızayı tolere etmek için 3 ESXi hostumuzun olması gerekecektir. Eğer 3 arızayı tolere etmek istiyorsak 2*3+1=7 ESXi hostuna sahip olmalıyız.

Son olarak fault domain konfigürasyonu yapılmamışsa ve fault domain veya host kaybı yaşanırsa, çabucak yeniden oluşturulamayacaktır. Bu durum için, VMware ek bir host veya Fault Domain bulundurulmasını tavsiye ettiğini belirtmek isterim.

Bugünlük de müessesemizden bu kadar. Yarın mesai var, ben kaçar. Herkese kolaylıklar 🐸

vSAN Node Management

vSAN ‘ı aktif etmek bir right click kadar yakın mesafededir. Yeni cluster oluştururken DRS’i , HA’i aktif etmek gibi kolaydır. ESXI hostları üzerinde vSAN platformunu koşturmak için ilave sanal makine yoktur. vSAN, ESXI üzerine gömülüdür. vSAN’ı kurmak diye bir şey yoktur, aktif etmek vardır.

Peki vSAN’ı aktif edebilmek için gereksinimler nelerdir?

1- Olmazsa olmazımız lisans : ) Kendisine ait farklı lisans modelleri bulunmaktadır.
2- Kullanılacağın vSAN türüne göre elinde ESXI hostlara takılı disklerinin bulunması gerekmektedir.
3- vSAN’da disk grupları oluşturabilmek, performans elde edebilmek, yedekliliği elde edebilmek için kesinlikle sunucular üzerinde bulunan Controller seçimi çok önemlidir. Tabii uygun olan firmware ve driver seçimi de önemlidir. Uyumsuz olduğu senaryolarda ciddi sorunlar oluşmaktadır. VMware Compatibility Guide a bakılarak seçim yapmak fayda sağlayacaktır.

Storage Controller Performansı

Kullanıcağınız donanım üreticisine ve desteklediği RAID controller modellerine göre vSAN’daki kullanılacak disklerin kullanım senaryoları da farklılık gösterir. Aşağıdaki ekranda 2 senaryo görüyoruz.

Passthrough mod: Sunucu üzerine takılan disklerin doğrudan hypervizöre gösterildiği ve RAID controllerda herhangi bir RAID aktivitesinin olmadığı, cache in devrede olmadığı bir yöntemdir. Buna bir diğer tabirle HBA metodu da denir. Controller üzerinde herhangi bir konfigürasyon yapılmasına ihtiyaç yoktur.

RAID O Mod: Bu modda hypervizor diskleri doğrudan görmez. Kullanılan ilgili storage controllerlarda her bir disk birbirinden bağımsız RAID 0 yapılarak sanki bir local VMFS datastore u sisteme kazandıracakmış gibi hypervizöre gösterilir.

Bu 2 yöntem arasında kullanmak isteyeceğimiz yöntem Passthrough yöntemidir. Daha az konfigürasyonu olduğundan ve troubleshooting daha kolaydır.

RAID in kullanılmış olduğu senaryolarda controllerların üzerinde de konfigürasyonlar yapmak gibi. Örneğin cache i kapatmak gerekmektedir. Kapatamıyorsanız read e çekilmelidir, write özelliğine yer vermemek gerekir. Write her zaman disklere doğru yapılmalı, controllerdaki cache de yapılmamalıdır.

Özetleyecek olursak, sunucuya taktığımız controllerlar, firmware i driver ı kesinlikle performansa etki etmektedir. Kullanılacak controller ın modları da yukarıda belirttiğim gibi etkilemektedir.

Ortamda birden fazla controller olmasında fayda vardır. Performans açısından etkilidir. Ayrıca ortamdaki single point of failure durumunu kaldırmış oluruz.

Mümkünse ESXI sunucuların power managementlarını high performance olarak ayarlanmalıdır. BIOS seviyesinde aşağıdaki gibi ayarlanırsa sağ taraftaki gibi VMware üzerinden high performance ayarlaması kolaylıkla yapılabilinecektir.

Skyline Health

Gerek vSAN’ın gerek vSphere’in sağlık durumunu temel seviyede konfigürasyonların doğru yapılıp yağılmadığını, üretici tavsiyelerine uyup uymadığını, üzerinde olabilecek zaafiyetlerin kapanıp kapanmadığı, donanımların vSAN’a uyup uymadıgını, driverlarının firmwarelerinin biribirne uyup uymadıgını kontrol eden yapıya denir.

Uyumsuzluk durumları performansı doğrudan etkileyeceği için ara sıra skyline health’te retest yapılmasında fayda olacaktır.

Serinin ikinci yazısının da sonuna geldik. Bir sonraki yazımda vSAN’ın arıza durumlarındaki davranışlarını ve dayanıklılığını konuşacağız.

Şimdilik hoşçakalın 🐸

Geleneksel Storage Yapısı

Geleneksel vSphere depolama çözümlerinde bir block storage dan gelen LUN’u bir VMFS Datastore olarak ya da File storagedan gelen NFS paylaşımını NFS datastore olarak ekleyerek ESXI hostlara depolama alanı sunulur. Kapasite ihtiyacını karşılamak, güvenliğini, yedekliliğini, yük dağılımını sağlamak için sanal makinelerin datastore’larda barındırılması gerekir. Fakat bu datastore’ların kesinlikle paylaşılan datastore’lar olması gerekir. Neden? Çünkü, bu alanları birden fazla ESXI host görebilsin ki biz aynı anda birden fazla sunucu tarafından bu ilgili depolama alanına erişebilelim, okuyabilelim yazabilelim diye. VMFS datastore filesystem gereğince aslında bir ortak depolama olmaya elverişli bir filesystemdir. NFS de aynı şekildedir. Daha ziyade Linux OS’in kullanımında gördüğümüz ve amacı Linux OS’lere öncelikle bir kaynak paylaştırmak ve o ilgili sisteme erişecek sistemleri eş zamanlı okumasına yazmasına izin verecek bir platformdur. Bu platformlar genel olarak geleneksel depolamalarla elde edilir. Ama artık ezber bozuldu : )

SDS & Hyperconverged SDS

*SDS: Software Defined Storage

Yıllardan beri söylenen neydi? ESXI hostların (yani bir fiziksel serverın) local disklerinde veri (yani sanal makine) barındırmamalıyız. Çünkü o fiziksel sunucunun disklerine okuma/yazma yapabilecek tek sistem ilgili fiziksel sunucudur. Dolayısıyla sizin oraya bir sanal makine barındırıyor olmanız sunucu kapandığında/sunucunun erişilemez hale geldiği senaryoda o veri gidecek ve o veriye hiçbir ESXI sunucu erişemeyecektir. Bu yüzden yıllarca geleneksel depolama dediğimiz filesystem VMFS ,NFS gibi tabirleri kullanılarak ESXI hostlarına bir depolama alanı sunulmuştur. Bu depolama alanları da her zaman bir storage unitesi ile beraber sunulmuştur. Çünkü storage ünitesi eş zamanlı birden fazla ESXI hosta bağlanabilir ve bu hostlar da bu alanları eş zamanlı okuyabilir ve yazabilirler. Host giderse o sanal makinelerin hiçbirine erişemezsiniz dedik yıllarca. vSAN’ın da aralarında bulunduğu yazılım tanımlı depolama çözümlerinin ortaya çıkmasıyla bu ezber bozulmuş oldu.

Artık sunucuların local diskleri diğer sunucuların local diskleriyle birleşerek ortak depolama alanı oluşturabilir duruma geldi. Yani artık üretim ortamı kurmak istediğimizde sunuculara ve depolamalar olarak bir platform kurmak yerine bir sunucunun hem sunucu hem de depolama olduğu bir mimariye geçebilir hale geldik. Bazı üreticiler bunu sadece bir yazılım olarak yaptılar, bazı üreticiler bunu hem yazılım hem donanımla birleştirilerek bir paket haline getirdiler. Bu yüzden de kullanılan iki tabir karşımıza çıktı. Biri SDS, diğer tabir ise Hyperconverged SDS. (Hyperconverged temelinde aynı olmakla beraber çözüm olarak birbirinden ayrılırlar. Örneğin vSAN bir SDS çözümdür.)

Hyperconverged çözümlerde; genel itibariyle bir üreticinin marka model sunucusu + sunmuş olduğu yazılım ile elde edilen bir tümleşik sistem bulunur. Üretici size yazılımı da donanımı da bir arada verir. Yani sunucuyu da sanallaştırma platformunu da bir arada verir ve size tümleşik bir sistem sunduğunu depolama ünitesi almanıza gerek kalmadığını, yani üçüncü bir çözüm olarak da depolamayı da sunduğunu söyler. Bunu bazı üreticiler donanımlar ile destekler bazı üreticiler de kullandıkları hypervizorleri üzerinde sanal makineler oluşturarak (controller vm, storage vm.. vb.) yaparlar. Sanal makineler bulundukları hostları temsilen yazılan bir veriyi diğer node a senkrron ederek aynı verinin diğer node üzerinde de bir kopyasının olmasını sağlarlar. Bu işlemi yaparken bazı üreticiler donanımla alakalı bağımlılıklara sahiptir, bazı üreticiler tümüyle yazılımla yaparlar. Bu temsilen hyperconverged tümleşik sisteminin örneğidir. VMware de tüm çözümlerini yazılım olarak dünyaya sunmaktadır. Bu yazılımlardan vSAN’ı inceleyelim.

Hoşgeldin vSAN ^_^

vSAN; Bir donanıma bağımlı olmadan, bir üreticiye bağımlı olmadan elde edilebilecek hem sunucu sanallaştırma hem depolama sanallaştırma mimarisini bize sunuyor. Bunu yaparken de sunucuların yerel disklerini kullanarak ortak bir depolama oluşturuyor.

Geleneksel mimari ile elimdeki 5 diski gruplayarak hem hata toleransı hem performans ihtiyaçlarına karşılık gelecek olan RAID yapısını oluşturmam gerekir. vSAN bize bu gruplamış olduğum disklerin hem performansı hem yedekliliği bir arada sunan ve bunu da geleneksel araçlardan kurtularak yapan bir nesne tabanlı bir depolama sunar. Burada obje kavramını iyi kavramak lazım. Örneğin sanal makinenin log dosyaları, hard diski, swap file ı, snapshotları bizim için bir objedir. Bizler bir sanal makine objesine dilediğimiz RAID politikasını soyleyerek istediğimiz korumayı , istediğimiz disk tipini söyleyebilir ve bunun yapılandırılmasını sağlayabiliriz. Bu işlem sırasında kullanılan disklerde hem bir sanal makinenin RAID5 diskine ait objesi dururken, hem de bambaşka bir sanal makinenin RAID1 objesine ait bir parça aynı diskin üzerinde durabilir. Yani geleneksel depolamada diskler korunurken ve dolayısıyla veri koruması böyle sağlanırken bizler artık vSAN’da disk koruması yapmak yerine diskin içerisindeki bir objeye/veriye politikalar vererek dilediğimiz konfigürasyonu sunabiliyoruz. Yani bizim için aslında diskler raw kapasiteyi oluşturuyorlar.

Vmware’in bizlere sunduğu kıymetli yetenekleri ( HA ve DRS gibi ) kullanmak için temel gereksinim ortak bir depolamadır. vSAN burada da hostların yerel diskleri birleşerek ortak bir depolama hizmeti sunması ile avantaj sağlamaktadır.

Geleneksel depolamada controller dediğimiz üniteler olur, bu controller ünitelerinin üzerinde cache ler ve ilgili sisteme eklemiş olduğunuz çekmeceler ve elde etmiş olduğunuz diskler yani kapasiteler bulunur. vSAN’a baktığımızda fiziksel sunucumuz bir storage ın ünitesi gibidir. vSAN üzerinde disk grup oluşturulur. Oluşturacağımız her bir disk grupta minimum 1 adet cache disk ve 1 adet minimum capasity disk barındırmak gerekir. Bu cache disk ya SSD ya da NVMe tarzda bir disk olacaktır. Çünkü RAM’e yakın, minimum letancy, maksimum i/o per second ile bir geleneksel depolaya karşın hizmet sunabilsinler. Capacity diskler ise sizin satın alacağınız mimariye , lisansa göre farklılık gösterebilirler. HDD ya da SSD/NVMe olabilir. Bu da karşımıza 2 farklı vSAN senaryosu çıkarmaktadır. Nedir bunlar?

Hybrid ve All-Flash.

Gelin vSAN’ın çalıştığı bu 2 mimariyi inceleyelim.

All-Flash: Cache in de kapasitenin de SSD ya da NVMe olduğu sistemdir.

Hybrid: Cache SSD ya da NVMe , capacity disklerin ise HDD olduğu mimaridir.

Cache de duran data ilgili disk grup ile ilgili temsilen veri barındırır. Dolayısıyla başka bir disk gruba replikası söz konusu değildir. Ayrıca bir disk grubunun içerisinde birden fazla cache eklenemez. Normalde geleneksel storage’da ne kadar çok disk, ne kadar çok cache o kadar performansken yeni nesil storage’da böyle değildir.

Kapasite ihtiyaçlarımıza göre disk gruplarımızın üzerine disk ilavesi yapabilir ya da disk gruplardan birden fazla oluşturabiliriz. Her bir disk grup içerisinde maksimum 7 tane disk barındırılabilir. Bunun dışında sunucu/host sayısını artırarakta kapasiteyi ve performansı arttırmak mümkündür. İşte burada sıklıkla duyduğumuz scale up , scale out büyüme karşımıza çıkıyor. İlk bahsettiğim disk grupları ile olan büyüme scale up büyümeye örnek iken node ekleyerek büyüme scale out büyümeye örnek olacaktır.

Piyasada tabir olarak kullanılan birkaç tane storage tipi bulunmaktadır.

1.Giriş seviyesi storageler
2.Orta seviye storageler
3.En yüksek seviye storageler

Giriş seviyesi storageların kabiliyetleri sınırlıdır. Ama orta ölçekli ve yüksek ölçekli diyebileceğimiz storagelar arasındaki fark controller sayısıdır.

Bir disk grubun bana sunacağı kapasite miktarını hesaplarken cache hesaba katılmaz. Mesela 5 hostumuz için 1 disk grubumuz olsun. Disk grubumuz içerisinde 2 capacity, 1 cache diski olsun. Her bir capacity disk 3 TB olsun. Bu durumda vSAN storage kapasitesi 3x2x5=30 TB olacaktır.

vSAN Cluster’lar disk yapılarına göre VMware’in izin verdiği en yüksek değerlere ulaşabilirler. vSAN cluster’ınız, tek bir cluster’da 64 ESXI sunucuya kadar büyüyebilir.

Buraya kadar iyilik sağlık : ) Şimdi biraz mola verelim. Serinin ilk yazısında geleneksel storage yapısından, yazılım tabanlı storage yapısından ve vSAN’dan genel anlamda bahsetmiş olduk. Serinin 2.yazısında vSAN Node Management üzerine konuşacağız.

Şimdilik hoşçakalın 🐸

NOT: Bu yazı serisini Ercan Ergen’den almış olduğum vSAN eğitimi notlarımdan derleyerek oluşturuyorum. Bu vesileyle kendisine bir teşekkürü borç bilirim.