Makalemin ilk bölümde Host ve vSAN trafiğinin çalıştırılacağı network switch tarafı için bazı dizayn önerileri hakkında paylaşım yapmıştık. Yazımızın 2.bölümünde Synergy frame interconnect konfigürasyon adımları ve vSAN aktif ederken önerilen bazı best practice’lerden bahsedeceğiz.
Makalemin ilk bölümü için aşağıdaki linki kullanabilirsiniz;
HPE Synergy Konfigürasyon Adımları
Bu vesile ile HPE Synergy interconnect mimarisi hakkında kısa bir bilgi vermek istiyorum. HPE Synergy Compassable mimarisi ile 5 tane frame birbirine bağlanabilir. Tek arayüzden, yönetiminin yanında sadece 2 frame üzerine takacağımız VC Modüle üzerinden tüm Network trafiğini yönetebiliriz.
Frameler üzerine taktığımız her VC Module 6 tane uplink port bulunur. Bu 6 portu 6 farklı şekilde konfigüre edebiliriz.
- 1x10G – takacağımız QSFP28 to SFP28 dönüştürücü üzerinde 10G SFP ile 1 tane 10G olarak
- 1x25G – takacağımız QSFP28 to SFP28 dönüştürücü üzerinde 25G SFP ile 1 tane 25G olarak
- 1x40G – takacağımız QSFP28 to SFP28 dönüştürücü üzerinde 40G SFP ile 1 tane 40G olarak
- 1x100G – takacağımız 100G SFP ile 1 tane 100G olarak
- 4x25G QSFP -takacağımız QSFP ile birlikte kullanacağımız MPO kablo ile 4 adet 25G olarak
- 4x10G QSFP -takacağımız QSFP ile birlikte kullanacağımız MPO kablo ile 4 adet 10G olarak
Logical İnterconnect Konfigürasyonu
Synergy Frame üzerine 6 tane Interconnect takılabilir. BAY1-BAY4 / BAY2-BAY5 / BAy3-BAY6 birbirlerinin yedeği olarak konfigüre edilir. Sunucuların üzerindeki mezzanine card’lar dual portlu olur ve 1.portu ilgili Primary Interconnect Module downlink portuna 2.portu Redundant Interconnect downlink portuna maplenmiş durumdadır.
Synergy Frame VC Modüle Redundant ve Non-redundant olmak üzere 2 farklı şekilde konfigüre edilebilir.
- Redundant – Bu konfigürasyon tipinde frame veya frame’ler üzerindeki tüm VC Modüle ve Interconnect Link Modüller aynı anda konfigüre edilir. HPE C7000 kullanıcıları anımsayacaktır, Chassie üzerindeki VC Modüllerin uplinkleri active/active konfigüre edilemiyordu. Synergy ile birlikte en büyük yeniliklerden biri de MLAG yapısı ile artık frame veya frameler üzerine takacağımız VC Modüllerin portlarını aynı MLAG yapısı ile aynı LACP grubu içerisine alabiliyoruz. Yukarıda ilettiğim bağlantı şekillerini kullanarak örneğin 4 tane 100G Portu aynı LACP grubuna alarak 400GB bir uplink grubu konfigüre edebiliriz. Aynı şekilde 2 farklı VC modüle maplenmiş olan sunucumuzun üzerine takılı network kartının her iki portunu LACP yapabiliriz. Bu da 1 sunucu üzerindeki 2 tane 50Gbs portu LACP ile 100Gbps bir bağlantı hızına çıkartabiliriz anlamına geliyor.
- Non-redundant – Bu konfigürasyon tipinide frame veya frame’ler üzerindeki VC Modüle ve Interconnect Link Modüller ayrı ayrı konfigüre edilir. Primary bölümdeki Interconnect Module A Side, Redundant bölümdeki Interconnect Module ise B side seçeneği ile konfigüre edilir. Açıkcası ben kişisel olarak A ve B side tarafındaki Interconnect Modulleri ayrı ayrı konfigüre etmeyi daha güvenilir buluyorum. Bu konfigürasyon’da bakım sırasında hangi VC Modüle hatta sunucunun hangi portunun etkileneceğini kontrol edebiliyorum.
Örnek bir Logical Inteconnect Uplink konfigürasyonu açıklamak gerekirse,
Q1 ve Q2 Portlarına 4x25G QSFP takılarak 1.Portları Esxi Management , 2.Portları vMotion, 3 ve 4. Portları ise VMNetwork için konfigüre edilmiş. Bu şekilde ; MGMT 50Gbps , vMotion 50Gbps , VMNetwork için ise 100Gbps network hızı sağlanmış durumda.
Q3 ve Q4 Portlarına 25G SFP takılarak Backup trafiği için 50Gbps network hızı sağlanmış
Q5 ve Q6 Portlarına 40G SFP takılarak vSAN trafiği için 80Gbps network hızı sağlanmış
tabiki bu konfigürasyon sadece bir örnek, bu bağlantılar elimizdeki mevcut kaynaklara göre şekillendirilebilir.
Storage Modüle Disk Ekleme
Frame üzerine takılan Storage Modüle ve sunucuların üzerindeki Raid Controller Interconnect Bay 1-4 deki SAS Modül üzerinden haberleşir. Her storage modüle üzerindeki disklerden disk groupları için JBOD tanımları oluşturulması gerekiyor. Daha sonra bu tanımları server profile oluştururken kullanacağız.
Buradaki kritik konu hostlara atayacağımız 2 disk group şekildeki gibi frame üzerindeki 2 farklı storage moduleden seçilmesi olacaktır. Oluşturacağımız bir Logical JBOD tanımı içerisinde kullanacağımız cache ve kapasite disklerini eklememiz yeterli olacaktır,
Buna ek olarak bu Storage Modüle içerisine konumlandırdığımız disklerinde dual port controller olması önemli. Eğer bu diskler single port olur ise tüm modülleri dual port konfigüre edilse bile herhangi bir modüle arızası veya firmware upgrade sırasında kesinti yaşanacaktır.
Server Profile Templete
Synergy Üzerinde hostlarımıza atadığımız Server Profile konfigürasyonunun en önemli kısmı hostumuzun network bağlantılarına karar verdiğimiz “Connections” adımıdır. Bu adımda vSAN Hostumuzun kaç adet network kartı olacak, bandwith nekadar olacak. Bunlara karar veriyoruz.
İdeal yapıda, hostlarımızın üzerinde 8 adet Network portunun olması faydalı olacaktır.
HPE Synergy’nin farkı bu aşamada ortaya çıkıyor. HPE Virtual Connect Module en sevdiğim özelliği sunucunun üzerine taktığımız 50Gb Network kartını toplam 16’a kadar istediğimiz 0,5 mbps – 50Gbps arasında istediğimiz hızlarda bölebilmemizin yanında Virtual Connect Modüle aslında bir network yönlendirme cihazı gibi çalıştığı için birbirinden izole çalışacak şekilde farklı networklere ait switchleri sonlandırabilmemiz. Özellikle vSAN ortamında buna çok ihtiyacımız olacaktır.
Sanal sunucuların Network trafiği için LAN switch, Backup network trafiği için Backup Switch ve vSAN networkün çalışacağı ayrı bir vSAN network switch yani 3 farklı switch’i tek bir Virtual Connect’de sonlandırıp sunucularımızın üzerindeki Network kartını bölerek birbirinden izole olarak tanımlayabilmemiz çok büyük fayda sağlıyor.
Şekildeki örnek Server Profile templete açıklamak gerekirse,
- vSAN Hostlarımızın Management ve vMotion trafiği için hostlarımızın üzerindeki 3.1-a ve 3.2-a portlarını
- Hostlarımız üzerinde çalışacak olan sanal sunucularımızın network trafiği için 3.1-b ve 3.2-b portlarını
- Sanal sunucularımızın Backup’larını almak için backup network trafiği için 3.1-c ve 3.2-c portlarını
- vSAN trafiği için ise hostlarımızın üzerindeki 3.1-d ve 3.2-d portlarını
Kullanılması için tanım yapılmış. Buradaki 3.1-x ve 3.2-x portlarını açıklamak gerekirse 3 Sunucunun üzerindeki Mezzanine Network kartın slot numarasını 1/2 network kartın port numarasını a/b/c/d ise bölümlendirdiğimiz port bilgisi olarak iletebiliriz.
Bu adımlar ile birlikte vSAN çalıştıracağımız ortamın Network ve Disk altyapısını hazırlamış olduk. Bundan sonraki aşamada artık hostlarımızın üzerine Esxi kurma adımına geçebiliriz. Version seçimi aşamasında bir yönlendirme daha yapmak istiyorum.
Esxi Version Seçimi
HPE her Esxi versionu için bir recipe dökümanı yayınlıyor, Son yayınlanan recipe dökümanına buradan erişebilirsiniz. Bu döküman bizi Synergy donanımlarımız için OS Support tool for HPE Synergy – HPE ‘e yönlendirecek. Bu matrixden kurulum yapacağımız versionu seçtiğimizde kullanmamız gereken OS kurulum ISO, firmware upgrade yaparken kullanacağımız SPP ISO bilgilerini görebiliriz.
**Dökümandaki note kısımlarını mutlaka dikkatlice incelemenizi tavsiye ediyorum.
Esxi Kurulumu
Vmware Esxi kurulumları donanım üreticilerinin Custom ISO’ları ile kuruluyor. HPE tarafında 3 farklı ürün ailesi için ayrı ISO yayınlanıyor. Sorun yaşamamak için kullandığımız donanıma uygun ISO ile kurulum yapılması kritik. Synergy kullandığımız için yayınlanan ISO ile OS kurulumunu yapabiliriz.
Virtual Distributed Switch Yapısı
Server profile tanımı yaparken hostlarımıza 8 tane port eklemiştik. Bu portları oluşturacağımız 4 VDS’de sonlandırabiliriz. Vmware best practice de aynı zamanda vSAN için ayrı bir VDS konfigure edilmesini önerir.
Witness Sunucu Konumlandırılması
Klasik vSAN ortamınlarından farklı olarak vSAN Streched cluster tüm aktif/aktif cluster yapılarda olduğu gibi hakem görevi yapan bir witness sunucuya ihtiyaç duyar.
vmware tarafında aslında bu vm klasik ova file üzerinden kurulan nested bir esxi sunucudur. Vmware Customer Connect üzerinden kurulumunu yaptığımız vSphere versionuna göre download edilir.
witnes sunucusunun 3. bir lokasyonda konumlandırılması öneriliyor. Hostlarımızın bu sunucuya 200msec latency ile erişmesi yeterli olacaktır. Default kurulumda vsan hostları ve witness sunucusu vsan network üzerinden haberleşmeye çalışır. vSAN Layer2 çalışan kapalı bir network olacağı için bu erişim sağlanamayacaktır. vSAN hostların witness sunucusu ile layer3 management network üzerinden çalışması için aşağıdaki komutun hostlar üzerinde çalıştırılması gerekecek
esxcli vsan network ip add -i vmk0 -T witness vmk0 hostun management vmkernel portu
vSAN Disklerin Eklenmesi
Hostlarımıza 2 farklı kutudan 2 farklı disk group eklemiştik, Bu disklerin fiziksel olarak hangi disk modülündeki hangi slotdaki disk olduğunu belirleyebilmek için aşağıdaki komutları kullanabiliriz.
cd /opt/smartstorageadmin/ssacli/bin/
./ssacli ctrl slot=1 pd all show detail
OS Kurulum Sonrası Uygulanması Önerilen Best Practice Adımları
Best Practice 1: Disk failover etmesi için gerekli komutların girilmesi.
vSAN için kullanacağımız disklerin seçimi yapılırken dual port controller olmasına dikkat etmemiz gerektiğini iletmiştik, Her iki controller’ın aktif aktif olarak kullanılabilmesi ve bir bakım veya SAS modüle arızası sırasında sorunsuz failover yapabilmesi için aşağıdaki komutların hostlar üzerinde çalıştırılması önerilir.
a. esxcli storage nmp satp rule add -D nhpsa -s VMW_SATP_DEFAULT_AP
b. esxcli storage core claiming unclaim -t driver -D nhpsa
c. esxcli storage core claimrule load
d. esxcli storage core claimrule run
Bu komutlar sonrasında disklerin path görünümü aşağıdaki ekran görünütüsündeki gibi Active/Active görünmesi gerekmektedir.
Best Practice 2: vSAN Network MTU 9000 yapılması.
vSAN için ayrı bir distributed switch konfigüre etmiştik. En önemli önerilerden bir tanesi vSAN networkünden uçtan uca MTU Size 9000 olarak ayarlanması.
Best Practice 3: Hostlar Üzerinde unicast trafiğin kontrol edilmesi.
vSAN 6.6 ile birlikte vSAN multicast yerine artık unicast olarak çalışmaktadır. oluşturduğumuz cluster’da vSAN enable edildikten sonra aşağıdaki komutlar ile hostlar üzerindeki vSAN trafiği unicast çalışıp çalışmadığı kontrol edilebilir.
esxcli vsan cluster get
Örnek Komut Çıktısı
esxcli vsan cluster unicastagent list
esxcli vsan network list
Best Practice 4: Site Read Locality ve Auto Rebalance
Streched cluster kurulumlarında datanın VM’in bulunduğu site tarafında okunması için “Advanced Options” kısmından bu seçeneğin ve bunun yanında yük dengelemesi için “Automatic Rebalance” seçeneğinin aktif edilesi öneriliyor. Özellikle Automatic Rebalance açma ile ilgili soru işaretleri olabilir. Bu seçeneğin aktif edilmesi ortama herhangi bir iş yükü getirmeyecektir. vSAN bu işlemi herhangi bir Sync operasyonu olmadığı zaman yani boşta kaldığı zaman gerçekleştiriyor.
Best Practice 5: HA Host Isolation Konfigürasyonu yapılması
vmware HA servisi çalışırken hostu ortamdan izole edip etmeyeceğine karar verirken management networküne erişim kontrolü yanında, klasik sanallaştırma ortamlarında SAN üzerinden tanımlanan SAN Datastore’ları kullanır. vSAN devreye girince ortamda SAN datastore kalmıyor. Hosta 2. bir kontrol noktası tanımlanması öneriliyor.
Bu aşamada en iyi çözüm disk trafiğimizin çalıştığı vSAN network switchlerinde vSAN vlanından SVI interface oluşturup HA Advanced Options kısmına bu SVI interface’lere verdiğimiz ip adreslerin girilmesi oluyor.
Ortamdaki tüm vSAN switchlerinde vSAN vlan’dan 1 tane SVI interface oluşturup ip adresi bilgilerinin girilmesi öneriliyor. Bu konfigürasyondan sonra eğer host bir nedenle Management Gatewaye erişemediğinde isole olmak yerine zaten hiç bir zaman kesilmemesi gereken vSAN networkü üzerinden de kendini kontrol edebilecek
Böylece HPE Synergy Üzerinde vSAN Streched Cluster aktif ederken yapılması gereken konfigürasyonlarımızı tamamlamış olduk. Yazımızın bir sonraki son bölümünde ise bu ortamın yük altında iken network, disk , SAS modüle gibi komponentleri kaybettiğindeki sonuçlarını paylaşacağım
Umarıım faydalı olmuştur.
Makalemin bir sonraki bölümü için aşağıdaki linki kullanabilirsiniz;
Eline sağlık. Çok güzel bir seri oluyor.