#vsan hangi cluster?

[tayfundeger]

New Post has been published on VMware Virtualization Blog

New Post has been published on http://www.tayfundeger.com/vsan-cluster-secenekleri-nelerdir.html

VSAN - Cluster Seçenekleri Nelerdir?

Merhaba,

Daha önce yazmış olduğum VSAN ile ilgili makalelerde cluster seçeneklerinden kısaca bahsetmiştim. Hatta bunlar ile ilgili kurulum makaleleride yazmıştım. Bu yazımda ise VSAN oluştururken hangi cluster’ı neden seçmeniz gerektiği konusunda detaylı bilgiler vereceğim. Ayrıca yine bu makale içerisinde Witness Host ile ilgilide bilgiler vereceğim. Witness ile ilgili ayrı bir makale yazmıştım ancak daha iyi anlaşılması için bu makale içerisinde de bilgi vereceğim.

Öncelikle VSAN ile ilgili yazmış olduğum makalelere aşağıdaki linkten ulaşabilirsiniz.

http://www.tayfundeger.com/kat/VSAN

VSAN’ı biz önceden manuel olarak yapılandırabiliyorduk ancak vSphere 6.7 U1 ile birlikte artık QuickStart Cluster wizard’ını kullanarakta yapılandırabiliriz. VSAN’ın eğer manuel veya QuickStart Cluster ile kurulum yapıyorsanız karşınıza belirli seçenekler çıkar. Depyloyment Type altında yer alan bu seçenekler aşağıdaki gibidir.

Single Site Cluster

Two host VSAN Cluster

Stretched Cluster

Ben bu yazımda yukarıda belirtmiş olduğum cluster seçeneklerinden kısaca bahsedeceğim. Hangi cluster seçeneğini nezaman kullanmalıyız bunların detaylarını anlatacağım.

Single Site Cluster:

Single Site Cluster yani Standard VSAN Cluster’ı oluşturacaksanız minimum 3 fiziksel ESXi host‘unuz bulunması gerekiyor. Siz isterseniz ESXi host sayısını 64’e kadar genişletebilirsiniz. İsmindende anlaşılacağı üzere cluster altında bulunan ESXi host’lar genellikle tek bir lokasyonda bulunur. Zaten önerilen konfigurasyonda tek bir lokasyonda olması gerektiği şekildedir.

Eğer siz farklı bir lokasyonda bulunan ESXi host’larınızı aynı VSAN cluster’ı altında barındırmak istiyorsanız Cluster seçeneğini değiştirmeniz gerekmektedir. Bunun için Stretched Cluster’ı kullanabilirsiniz. Single Site Cluster seçeneğini seçiyorsanız ESXi host’larınızın Layer 2 seviyesinde birbiri ile haberleştiğinden emin olmalısınız. All flash bir yapı kullanıyorsanız network NIC’leriniz 10GbE hıza sahip olmalıdır. Eğer Hybrid bir yapı kullanıyorsanız 1GbE network NIC’leri kullanabilirsiniz. Ancak VMware burada VSAN altyapısında kullanacağınız tüm NIC’lerin 10GbE hızında olmasını ve bunların redundant yani yedekli bir şekilde çalışmasını tavsiye ediyor.

Two host VSAN Cluster:

2 Node ile VSAN Cluster’ı oluşturma seçeneği VSAN 6.1 ile birlikte geldi. 2 Node’lu VSAN Cluster’ıda yine Single Site Cluster‘da olduğu gibi aynı lokasyonda bulunur. Eğer sizin uzakta bulunan ofisleriniz var ise ve burada düşük maaliyetli bir çözüm sunmak istiyorsanız Two host VSAN Cluster seçeneği tam size göre. Sahip olduğunuz 2 fiziksel ESXi host ile bir VSAN cluster’ı oluşturabilrisiniz. Bu hostlar genellikle aynı network switchine veya doğrudan birbirlerine bağlıdırlar. Hostların doğrudan birbirine bağlanması durumunda; pahalı network switchlerin satınalınması ve yönetilmesi sürecinin önüne geçilmiş olur. Bu da düşük maliyet avantajı sağlar, özellikle uzak ofis senaryoları için uygun olabilir.

2-Node cluster yapısında, 2 node arasında network erişimi kaybolduğunda,  “Split-Brain” problemleri yaşamamak için, 3. vSAN Witness Host’a ihtiyaç vardır. VSAN Witness Host ile ilgili daha önce ben aşağıdaki gibi bir makale yazmıştım ancak bu makalemde de ayrıca değineceğim.

VSAN – Witness Appliance Nedir? Ne iş Yapar?

Stretched Cluster:

VSAN 6.1 ile birlikte gelen yeniliklerin bir diğeride Stretched Cluster idi. Stretched Cluster mimarisinde bir lokasyonu komple kaybetme riskine karşı esneklik sağlar. Daha iyi anlaşılması için şöyle örnek verelim. 2 farklı datacenter/lokasyon üzerinde ESXi host’larınız bulunuyor. Tasarladığınız mimaride aynı zamanda datacenter/lokasyon yedekliliğide olmasını istiyorsunuz. Böyle bir durumda VSAN Stretched Cluster’ı kullanabiilrsiniz. 2 farklı datacenter/lokasyon da bulunan ESXi host’larınızı tek bir cluster altında toplayabilir ve herhangi bir datacenter/lokasyonun down olması durumunda veri kaybı yaşamadan diğer datacenter/lokasyon’dan devam eder. Tabi burada sizing’i doğru bir şekilde yaptığınızı düşünerek bu örneği veriyorum.

vSAN Stretched Cluster içerisndeki hostlar 2 lokasyon arasında eşit olarak dağıtılmıştır. İki yapıdaki tüm hostlar networksel olarak, 5 ms’nin altında bir “round trip time” (RTT) ile bağlıdır.  2 node cluster yapısındaki gibi, 2 lokasyonun erişiminin kesilmesi durumu için 3. bir lokasyonda vSAN Witness Host kurulumu yapılır. Witness ile host’lar arasındaki RTT ise en fazla 200ms olması gerekir. Belirtmiş olduğum RTT süreleri yerine getirildiği sürece herhangi bir kısıtlama ile karşılaşmazsınız. vSAN Stretched Cluster yapısında en fazla 30 host bulunabilir  ve lokasyonlar arasında eşit sayıda veya farklı sayılarda kurulabilirler.

Son olarak Witness hakkında bilgi vermek istiyorum.

VSAN Witness Host

2 Node’lu ve Stretched Cluster vSAN kurulumlarında vSAN Witness Host kullanımın anlamak önemlidir. Ben daha önce Witness Appliance ile ilgili bir makale yazmıştım. Buna yukarıdaki linkten ulaşabilirsiniz. Witness Host “witness components” diye anılan vSAN objelerinin metadata verisini saklar.  VM verileri, sanal disk, VM konfigürasyonu gibi veriler Witness Host’da saklanmaz. VSAN Witness Host kullanım amacı; lokasyonlar arasında networklerin birbirine erişiminin kopması durumu için bir kontrol noktası olmasıdır.

vSAN Witness Host fiziksel bir sunucu olabileceği gibi, VMware portalinden indirebileceğiniz OVA formatı üzerinden kurulumu yapılabilen bir virtual appliance da olabilir. Fiziksel bir sunucuda kurulum yapılması durumunda ayrı lisans gereklidir ve genel konfigürasyon gereksinimlerinin karşılanması gereklidir. Tabi burada lisans gereklidir diyorum ancak VSAN cluster’ında kullanılan ESXi’lar ile aynı lisansa sahip olmak zorunda değildir. VSAN Witness Host’un ESXi versiyonu, VSAN cluster’ında bulunan ESXi host’lar ile aynı build’de olması gerekir. Appliance olarak kurulmak istendiğinde ek lisans gereksinimi olmaksızın, mevcut vSphere  altyapısı kullanılabilir. Sanırım ilerleyen günlerde Witness Host’un gereksinimleri ile ilgili ayrıca bir makale yazacağım 🙂

2 Node cluster kullanım senaryosunda, uzak ofis lokasyonları gibi, vSAN Witness Appliance genellikle birincil (PROD) veri merkezinde kurulur. Bu senaryoda, Virtual Appliance uzak ofis lokasyonunda da konumlandırılabilir fakat ek altyapı kaynakları gereksinimi oluşabilir.

Streched Cluster yapısında, vSAN Witness Host üzerinden birincil ve ikincil veri merkezlerinden bağımsız olarak üçüncül bir veri merkezi üzerinden kontrol sağlar. Her bir 2 Node Cluster veya Stretched Cluster kurulumu için bir vSAN Witness Host gereklidir.

Şimdi asıl önemli konuya değinmek istiyorum.

vSAN Witness Host network hat genişliği gereksinimi vSAN bileşen sayılarına bağlı olarak hesaplanır. Failover senaryosu esnasında, vSAN bileşenlerinin sahipliği, sistemin devam edeceği lokasyona (ikincil) 5 sn’nin üzerinde bir sürede taşınmalıdır. Buradaki kural, her 1000 vSAN bileşeni için 2Mbps olarak hesaplanabilir. Maximum network latency, VSAN Witness Host’a bağımlı clusterdaki host sayısı üzerinden hesaplanır. 2 Node vSAN Cluster konfigürasyonunda en fazla 500ms’ye kadar, Stretched Cluster yapısındaysa, clusterdaki host sayısına bağlı olarak, 200 ms veya 100 ms’ye kadar latency gereksinimi vardır. Dolayısıyla network hattı burada oldukça önemli.

Genellikle, VSAN Witness Appliance kullanmak fiziksel vSAN Witness host kullanımına göre daha çok tavsiye edilir. Fiziksel cihaz konumlandırmanın hem maaliyeti hemde donanım yönetimi yüzünden çok tercih edilmiyor. Normal operasyon zamanlarında VSAN Witness Host’un kaynak kullanımı genellikle oldukça düşüktür. Bu nedenle, özellikle 2 Node yapılarında, Witness Host appliance olarak kullanılabilir. VMware , vSphere 5.5 ve üzeri sürümlerde Appliance kullanımı desteklenmektedir.  VSAN Witness Appliance güncellemesi , aynı ESXi güncellemesi gibi yapılabilir.

Umarım faydalı olmuştur.

İyi çalışmalar.

[tayfundeger]

New Post has been published on VMware Virtualization Blog

New Post has been published on https://www.tayfundeger.com/vsan-file-services.html

vSAN File Services

Merhaba,

vSAN File Services isimli bu yazımda sizlere vSAN 7 ile birlikte gelen yeniliklerden biri olan vSAN File Services hakkında bilgi vereceğim. Daha önce vSAN 7 ile birlikte gelen yenilikleri yazmıştım. Bu yazıma aşağıdaki linkten ulaşabilirsiniz.

VSAN 7 Yenilikleri

Çok kafa karıştırmadan sade bir biçimde File Services’i anlatmak istiyorum. vSAN File Services sayesinde, vSAN datastore’u kullanılarak bir NFS paylaşımı yapabiliriz. Yani bu ne demek oluyor? vSAN File Services, dosya paylaşımları sağlamak için vSAN’ın üzerine oturan bir katmandır. Şu anda SMB, NFSv3 ve NFSv4.1 dosya paylaşımlarını desteklemektedir. vSAN datastore’undan oluşturacağınız NFS paylaşımlarını bir sunucuya mount edebilirsiniz. Böylece vSAN datastore’unda bulunan kapasitesinizi NFS, SMB gibi paylaşımlar ile depolama amaçlı kullanabilirsiniz. Tüm bu yapacağınız işlemler vSAN Distributed File System yani vDFS üzerinde gerçekleşir. Bundan dolayı yaptığınız share işlemleri vSAN Storage Policy tarafından desteklenir. Yani oluşabilecek hatalardan, disk bazl�� sorunlardan minimum seviyede etkilenirsiniz.

vSAN File Services

vSAN 7.0 Update 1 ile ise, SMB desteğide sunulmaya başlanmıştır. Normalde vSAN 7 ‘de sadece NFS desteği bulunuyor Update 1 ile SMB desteğide geldi. Active Directory üzerinde bulunan bir kullanıcıya yetkilendirme yapılarak paylaşımlara erişim izni verebilirsiniz. İlerleyen sürümlerde farklı desteklerinde geleceğini düşünüyorum. Açıkcası vSAN File Services’in, Tanzu ve Kubernetes gibi altyapılarda aktif olarak kullanılacağını düşünüyorum.

vSAN File Services

Ayrıca daha önceki makalelerimde Cloud Director’un kurulumunu anlatmıştım.

Cloud Director 10 Kurulumu Bölüm 2 – NFS

Bu kurulumda NFS paylaşımı olarak Windows’u kullanmıştım. Eğer sizlerin vSAN 7 ve sonraki versiyonlara sahip bir altyapınız bulunuyor ise, burada vSAN File Services’i kullanıp Cloud Director kurulumunda NFS paylaşımını vSAN üzerinden verebiliriz. Böylece NFS için ekstra olarak bir sunucu bulundurmak zorunda kalmayacaksınız veya NFS sunucu yönetimi ile uğraşmayacaksınız.

vSAN File Share‘in bazı limitasyonları bulunmaktadır. Bunları kısaca sıralayacak olursak;

vSAN Cluster’ında maintenance mode’a alınan bir ESXi host olduğunda, o ESXi host üzerinde bulunan File Service VM otomatik olarak power off olur ve silinir. Maintenance mode’dan çıkarıldığında ise Virtual machine tekrar deploy edilir.

vSAN 7.0 Update 1, 32 File Share ve 32 File Server (ESXi node) desteklemektedir.

vSAN File Shares kullanarak oluşturduğunuz NFS paylaşımını ESXi host’a ekleyip üzerinde Virtual Machine barındırmamalısınız. Bu işlem unsupported ‘dır.

Önemli: 2 node vSAN ve Stretched Cluster support edilmemektedir. Bu vSAN 7 versiyonu için geçerlidir. İlerleyen versiyonlarda bu destek gelebilir.

vSAN File Services aktif etmek için öncelikle vSAN Cluster’ını seçiyoruz ve Configure > vSAN Services bölümüne giriş yapıyoruz.

vSAN Services bölümüne giriş yaptığımızda File Services bölümünde Enable butonuna basıyoruz.

Introduction bölümünde vSAN File Services’in nasıl çalıştığını anlatan bilgiler yer alıyor. Aynı şeyleri yukarıda da anlattım. Burada da göreceğiniz üzere File Services vDFS’in üzerinde çalıştığı için oldukça güvenlidir. Storage Policy’de belirlemiş olduğunuz ayarlar aynı zamanda File Services içinde geçerli olduğu için bize maksimum koruma sağlamaktadır.

File Services’i kullanabilmeniz için static bir IP adresine ihtiyacınız bulunmaktadır. Çünkü burada bir file share oluşturacağınız için bu file share’a ulaşabilmesi için bir IP gerekli. Örneğin Linux bir sunucuya NFS mount ederken burada belirteceğiz IP adresini kullanacaksınız. Aşağıdaki gereksinimleri karşılamayı unutmayın.

Static IP address

Subnet mask ve Gateway

DNS server (geçerli bir A kaydı)

Reverse DNS lookup

Next ile devam ediyoruz.

File Services’i kullanabilmeniz için File Service Agent’i download etmeniz gerekir. Burada Automatic approach seçeneğini seçerseniz en son çıkan File Services Appliance’i otomatik olarak download eder. Ancak siz kendiniz manuel olarak download etmek isterseniz Manual approad seçeneğini seçip ilerleyebilirsiniz. Ben Automatic approach seçeneğini seçiyorum ve OVF dosyasını download ediyorum. Bu işlemi yaptıktan sonra File Service agent bölümü bir daha karşınıza çıkmaz.

Next ile devam ediyorum.

Ben DNS üzerinde vsanfs isminde bir A kaydı oluşturdum ve bunun Reverse DNS kaydınıda yaptım. File Service domain bölümünde DNS üzerinde oluşturduğunuz ve vSAN File Share için kullanacağınız ismi giriyoruz.  DNS ve DNS Suffixes bölümünü dolduruyoruz. Directory Service bölümünü isterseniz yapılandırabilirsiniz. Kimlik doğrulama için bir Active Directory domain’ini kullanabilirsiniz. Kerberos kimlik doğrulamasıyla bir SMB dosya paylaşımı veya NFSv4.1 dosya paylaşımı oluşturmayı planlıyorsanız, vSAN File Services için bir Active Directory domain’i  yapılandırmanız gerekir. Ben şuan için bunu seçmiyorum.

Next ile devam ediyoruz.

Networking bölümünde File Services‘in kullanacağı network, subnet mask ve gateway’i belirtiyoruz. Ben test ortamımda dedicated bir portgroup belirtmedim ancak sizler production ortamında kullanacaksanız dedicated bir portgroup belirtmenizi tavsiye ederim. Ayrıca Distributed Switch versiyonunun 6.6.0 veya daha üst bir sürüme sahip olmalıdır. Ben burada Standard switch üzerinde konfigurasyon yaptığım için default olarak bırakıyorum ve Next ile devam ediyorum.

Son olarak IP pool bölümünde deploy edilecek olan File Service Agent üzerine IP’lerin belirlenmesi gerekiyor. vSAN Cluster’ınızda kaç adet ESXi host bulunuyor ise o kadar File Service Agent deploy edilecek ve bu sunucuların herbirinin bir IP adresi ve DNS kaydı olması gerekmektedir. Belirteceğiniz her IP adresinin DNS üzerinde mutlaka bir kaydı olması gerekmektedir. Autofill butonuna bastığınızda IP adreslerini sıralı bir biçimde dolduracaktır. Lookup DNS butonuna bastığınızda ise yazmış olduğunuz IP adreslerinin DNS üzerindeki karşılıklarını otomatik olarak yazacaktır. Tüm bilgileri doldurduktan sonra Next butonu ile devam ediyoruz.

Son olarak yapmış olduğumuz işlemlerin kısa bir özetini görüyoruz ve Finish butonu ile işlemi başlatıyoruz.

  File Service’in oluşturulma işlemi biraz zaman almaktadır. Çünkü File Service Agent’in download edilip her host üzerine import edilme işlemi ve bunlara IP atama işlemleri zaman alabilmektedir. Kurulumun tüm detaylarını tasks üzerinden takip edebilirsiniz.

File Service üzerinde yapmış olduğumuz ayarların hepsini vSAN Cluster > Configure > vSAN Services bölümü altında görebilirsiniz.

File Service başarılı bir şekilde aktif hale geldikten sonra Cluster altında ESX Agent isimli bir Resource Pool oluşacaktır. Bu Resource Pool altında vSAN File Service Agent’ları çalışacaktır.

Peki File Service’i aktif ettik, bunu bir sunucuya nasıl mount edebiliriz onu göstermek istiyorum.

vSAN Cluster > Configure > File Shares bölümüne giriş yapıyoruz ve burada Add butonuna basıyoruz.

General bölümünde vSAN File Share ile ilgili bazı bilgiler yazmamız isteniyor. Name bölümünde paylaşımın ismini belirtiyoruz. Protocol olarak NFS seçiyoruz. Versions olarak ben default bırakıyorum ancak siz isterseniz sadece NFS 3 veya NFS 4.1 seçebilirsiniz. Storage Policy bölümünü default olarak bırakıyorum. Çünkü bu share yani paylaşım için özel bir policy belirtmedim.

Oluşturacağınız bu paylaşıma isterseniz bir kota belirtebilir hatta belirtmiş olduğunuz sınıra geldiğine size uyarı vermesini sağlayabilirsiniz. Ben burada kota olarak 10 GB, warning olarak ise 5 GB tanımladım. Label bölümünde ise isterseniz bu paylaşımı ne amaç ile kullanacağınızı belirtebilirsiniz.

Next butonu ile devam ediyorum.

Oluşturduğunuz bu paylaşıma hangi IP’lerin erişeceğiniz belirtebilirsiniz. Ben burada Allow access from any IP seçiyorum. Herhangi bir IP kısıtlaması olmaksızın tüm IP’lerden bu paylaşıma bağlantı sağlanabilsin. Eğer isterseniz Customize net access seçeneğini seçerek bir IP bloğu belirtebilirsiniz.

Next ile devam ediyoruz.

  Tüm işlemleri tamamladıktan sonra Finish butonu ile işlemi tamamlıyoruz.

Paylaşımımız başarılı bir şekilde oluştu. Şimdi ben bu paylaşımı bir Windows sunucuya mount edeceğim. Altyapımda Linux bir sunucu olmadığı için Linux üzerinde test edemiyorum maalesef 🙂

Copy Path butonuna bastığınız bu paylaşımın adresini kopyalayabilirsiniz.

Windows sunucum üzerinde aşağıdaki komutu çalıştırıyorum.

[php]

mount -o nolock vsanfs1.tayfundeger.local:/vsanshare z:

[/php]

mount -o nolock yazıp daha sonrasında copy path bölümüne bastığımda kopyalanan path’i yapıştırıyorum. Komutun sonuna ise drive ismini belirtiyorum.

vSAN File Services kullanarak oluşturduğumuz paylaşımı Windows sunucuma mount ettim.

Son olarak vSAN File Shares bölümünde, doluluk oranlarınız görebilirsiniz.

vSAN File Shares ilerleyen zamanlarda çok aktif kullanacağımızı düşünüyorum. Çünkü container mimarilerinde NFS paylaşımlarına ihtiyacımız bulunabiliyor. Böyle bir durumda eğer vSAN kullanıyorsanız vSAN File Shares‘i kullanabilir ve böylece işlerinizi hızlı/basit bir şekilde çözebilirsiniz. Ayrıca oluşturacağınız bu File Share, vSAN Storage Policy ile korunduğu için oluşabilecek hatalardan minimum seviyede etkilenirsiniz.

Umarım faydalı olmuştur.

İyi çalışmalar.

[tayfundeger]

New Post has been published on VMware Virtualization Blog

New Post has been published on https://www.tayfundeger.com/vsan-compression-only.html

vSAN Compression Only

Merhaba,

vSAN Compression Only isimli bu yazımda sizlere vSAN 7 U1 ile birlikte gelen Compression yeniliğinden bahsedeceğim. vSAN 6.2 versiyonundan itibaren Deduplication ve Compression özelliği kullanılmaya başlandı.

Ben daha önce Deduplication ve Compression’i anlatmıştım. Bu yazıma aşağıdaki linkten ulaşabilirsiniz.

VSAN 6.2 – Deduplication ve Compression

Deduplication ve Compression’ın doğrudan kapasiteye etkisi vardır. vSAN kullanıyorsanız Deduplication ve Compression seçeneğini yanlızca All Flash mimaride kullanabiliyorsunuz. All flash ve Hybrid konfigurasyon arasındaki farkı bilmiyorsanız aşağıdaki makalemi inceleyebilirsiniz.

VSAN – All Flash ve Hybrid

Deduplication’i incelediğiniz aslında yapı itibari ile performans kayıplarının olması normal karşılanıyor. Ancak bazı durumlarda deduplication’i devre dışı bırakmak isteyebilirsiniz. Yüksek performanslı SAP ve SQL veritabanlarında compression’in aktif olması performansı artırırken disk alanından tasarruf sağlar. Bu özellikten deduplication gereksinimini ortadan kaldırarak, kullanıcıların artık daha iyi disk kullanımının etkinleştirilmesinin, yalnızca bir diski kaybederlerse tüm bir disk grubunun başarısız olmasına neden olacağından endişelenmeleri gerekmez.

vSAN Compression Only

vSAN ‘da Deduplication ve Compression oldukça önemli bir özelliktir. Çünkü doğrudan datastore’un free space’ine etki eder. Bu durum kaynakları daha verimli kullanmanızı sağlar. Ancak vSAN 7.0 U1 ile birlikte gelen Compression Only seçeneğinin avantajı sadece kapasite değil. Bununla birlikte aslında arıza toleransı konusunda da size farklı avantajlar sunuyor.

  vSAN Compression Only

vSAN ortamında Deduplication ve Compression seçeneklerini aktif etmek için Cluster > Configure > vSAN Services bölümüne giriş yapıyoruz. Space Efficiency bölümüne giriş yapıyoruz.

Space Efficiency bölümüne giriş yaptığınızda karşımıza 3 tane seçenek çıkıyor. Daha önceki sürümlerde Deduplication ve Compression’i sadece aktif veya pasif duruma getirebiliyorduk. vSphere 7.0 U1 ‘de ise Deduplication ve Compression’i aynı anda aktif edebiliyorsunuz yine ancak bu sürümde isterseniz sadece Compression’ida aktif edebiliyorsunuz.

Compression Only seçeneğini seçtiğinizde ne kadar bir yer tasarrufu sağlanır bunu bilemeyiz. Çünkü burada her Virtual Machine’in sahip olduğu konfigurasyona göre değişkenlik gösterir.

Compression Only seçeneğini seçtiğinizde Deduplication ve Compression seçeneğine göre daha iyi bir performans sergileyebilir. Hatta okumuş olduğum bir raporda database gibi SAP gibi uygulamalarda önceki vSAN versiyonlarına göre %58’e yakın bir performans iyileşmesi olduğu belirtiliyor. Compression Only seçeneğini seçtiğinizde performansa olan etkisini büyük cluster’larda daha iyi anlayabilirsiniz. Çünkü çok fazla sayıda virtual machine’in bulunduğu cluster’larda deduplication’in aktif olmayıp sadece Compression’in aktif olması durumunda Deduplication engine’inin çalışmayacak olması performansa olumlu etki edecektir. Çünkü cache disk üzerine aynı veri birden fazla yazılabilir. bu işlemler bittiğinde kapasite diskine veriler indirilmeye başlandığında aynı veriler kapasite diskine yazılmaz. vSAN, Compression yaparken LZ4 algoritmasını kullanır ve bunu 4KB bloklar üzerinde yapıyor.

Peki buraya kadar herşey normal. Yukarıda sizlere sadece Compression Only seçeneğini seçtiğinizde sadece kapasiteye faydası olduğu gibi arıza toleransınada faydası var diye bahsetmiştim. Peki bu nasıl oluyor?

Deduplication ve Compression seçeneğini seçtiğinizde eğer kapasite disklerinden biri arızalanırsa tüm disk grubu etkilenir. Bunun sebebi Deduplication bilgilerinin cluster’da bulunan kapasite disklerinde tutuluyor olmasından kaynaklanıyor. Ancak Compression Only seçeneğini seçtiğinizde bu durum biraz daha farklı. Compression Only seçeneğinde disk arızası olduğunda yanlızca o disk etkilenir, tüm disk grubu etkilenmez.

Burada hangi seçeneği seçmeniz gerektiği konusunda ise VMware bizimle ufak bir bilgi paylaşıyor.

Workload Recommendation Capacity Savings Performance Impact OLTP databases Compression Only Moderate Minimal Mixed workloads Compression Only Moderate Minimal VDI using instant clones Compression Only Moderate Minimal VDI using linked clones Compression Only Moderate Minimal VDI using full clones DD&C High Moderate

VMware, yukarıdaki iş yükü tiplerine göre Deduplication ve Compression veya sadece Compression kullanılması konusunda önerilerde bulunuyor. Eğer siz yukarıdaki tabloya rağmen neyin kullanılacağından tam emin değilseniz, minimum performans etkisiyle ve alan tasarrufu ile işle yapmak istiyorsanız sadece Compression Only seçeneğini seçebilirsiniz. Bu aslında VMware’in önerisi. Yukarıda da belirttiğim gibi Deduplication işin içerisine girdiğinde ister istemez bir algoritma çalışacağı için performansa bazı etkileri olabilir. Elbette burada yarı yarıya bir performans farkıda beklememek lazım.

Yukarıda Deduplication ve Compression aynı anda aktif olduğundaki performans ile Compression Only seçeneği seçildiğinde karşılaşacağımız performans etkileri yukarıdaki gibi olacaktır.

Özetlemek gerekirse, vSAN alternatiflerine bakıldığında Deduplication ve Compression’i devre dışı bırakabildiğiniz gibi isterseniz sadece Compression ‘i aktif edebileceğiniz bir mimari sunuyor bize. Aklınıza şu gelebilir hangi şartlarda Deduplication ve Compression devre dışı bırakabilirim diye sorabilirsiniz. Yoğun IO gerektiren veya üst düzey performans beklentilerinin olduğu ortamlarda bu özelliği kapatmanız istenebilir veya kapatmak zorunda kalabilirsiniz. Microsoft SQL Server ve Oracle Database gibi bazı veritabanı çözümleri native compression içerir. Etkinleştirilirse, bu muhtemelen vSAN Deduplication ve Compression faydalarını azaltacaktır. Veritabanı Compression etkinleştirilmediği ortamlar için, vSAN Deduplication ve Compression daha uygun sonuçlar vermektedir. Yani deduplication ve compression, virtual machine’lerin içerisinde barındırdığı uygulamaya bağlı olarak performans farkı yaratır.

Genel olarak, okuma performansı, Deduplication ve Compression daha az etkilenir. vSAN ilk olarak bir read talebi geldiğinde cache üzerinden bir read talebini yerine getirmeye çalışacaktır. Eğer bu veriler cache üzerinde bulunmuyor ise, vSAN’ın cache tier’da aranmaya başlar. Veriler, cache veya vSAN cache tier’da tekilleştirilmez ve sıkıştırılmaz (deduplication ve compression). Bu nedenle, veriler teslim edilmeden önce, verileri yeniden derlemek ve sıkıştırmasını açmak zorunda kalmanın bir performans kaybı olmaz. Bununla birlikte, vSAN kapasite katmanından gelen read verileri, yeniden derlenirken ve sıkıştırılmış durumdan çıkarılırken az miktarda kaynak ek yükü oluşturacaktır.

Testler ile ilgili daha detaylı makale için aşağıdaki link’i inceleyebilirsiniz.

https://infohub.delltechnologies.com/l/harnessing-the-performance-of-dell-emc-vxrail-7-0-100-a-lab-based-performance-analysis/conclusion-3-vsan-compression-only-is-nearly-penalty-free

Umarım faydalı olmuştur.

İyi çalışmalar.

[tayfundeger]

New Post has been published on VMware Virtualization Blog

New Post has been published on https://www.tayfundeger.com/vsan-ve-memory-tuketimi.html

VSAN ve Memory Tüketimi

Merhaba,

VSAN ve Memory Tüketimi isimli bu yazımda sizlere VSAN kullanılan ortamında VSAN’ın fiziksel sunucu üzerindeki memory tüketiminin nasıl olduğunu anlatacağım. Ben daha önce VSAN ile ilgili bir çok makale yazmıştım bu yazılarıma aşağıdaki linkten ulaşbilirsiniz.

https://www.tayfundeger.com/kat/VSAN

VSAN biliyorsunuz ki Hypervisor seviyesinde çalışan bir servistir. Biz VSAN sayesinde, storage olmayan/bulunmayan ortamlarda cluster yapabiliyoruz. Her bir sunucu üzerinde bulunan diskleri kullanarak shared bir datastore oluşturabiliyoruz.

VSAN ve Memory Tüketimi

VSAN, Hypervisor seviyesinde bir servis olduğu için fiziksel sunucu üzerinde ek bir yük oluşturmaktadır. Ben bu yazımda sizlere VSAN’ın ihtiyaç duyacağı ek memory miktarı hakkında detaylı bilgiler vereceğim. Bu makalemi yazarken burada belirtmiş olduğum KB’den faydalanacağım.

Eğer VSAN kullanacaksanız kapasite planlaması oldukça önemlidir. Bir çok kişi/kurum bu konularda ciddi hatalar yaptığı için tekrar konfigurasyon çalışmak durumunda kalabiliyorlar. Aslında burada yapılacak işlemler basit bir matematik hesabından ibarettir. Sadece bu hesaplamayı yaparken hangi değişkenleri kullanacağınızı ve konfigurasyonunuz içindeki verilere dikkat etmeniz gerekiyor.

Daha öncede belirttiğim gibi ESXi üzerinde çalışan bir servis olduğu için kapasite planlaması yapılırken memory tüketiminide hesaplamanız gerekiyor. Bunun hesaplanma yöntemi oldukça basit aslında. VSAN’ın harcayacağı memory miktarını hesaplarken kullandğımız bazı sabit değerler vardır. Bu değerler ile mevcut disk konfigurasyonunuzdaki değerleri hesapladığınızda aslında kullanılacak veya tüketilecek memory miktarını öğrenebilirsiniz.

Öncelikle bu sabit değerler hakkında bilgi vermek istiyorum.

OST_FOOTPRINT = 7100 MB CAPACITY_DISK_FOOTPRINT = 160 MB (ALL_FLASH) CACHE_DISK_FOOTPRINT = 20 MB (ALL_FLASH) DISKGROUP_FIXED_FOOTPRINT = 1360 MB (ALL_FLASH) * CAPACITY_DISK_FOOTPRINT = 180 MB (HYBRID) CACHE_DISK_FOOTPRINT = 10 MB (HYBRID) DISKGROUP_FIXED_FOOTPRINT = 1610 MB (HYBRID) DISKGROUP_SCALABLE_FOOTPRINT = 0.5% of system memory

VSAN ortamlarında deduplication ve compression özelliklerini aktif veya pasif kullanabiliyorsunuz. Elbette Deduplication ve Compression özelliği sadece all flash konfigurasyonunda geldiğinide ayrıca belirtmek isterim. Eğer Deduplication ve Compression ile ilgili detaylı bilgiye ihityacınız var ise aşağıdaki makalemi inceleyebilirsiniz.

VSAN – All Flash ve Hybrid

Eğer ortamınızda deduplication açık durumda ise her disk grubu başına ek 120MB ihtiyacı bulunmaktadır. VSAN Disk Grupları ile ilgili aşağıdaki makalemi inceleyebilirsiniz.

VSAN Disk Groups

Öncelikle yukarıda belirtmiş olduğum değerlerin ne anlama geldiğini açıklamak istiyorum.

HOST_FOOTPRINT: Herhangi diskgruplarına bakılmaksızın her ESXi Host için VSAN tarafından tüketilen bellek miktarı NumDiskGroups: ESXi host’lardaki disk gruplarının sayısı. (1-5 aralığı) DiskGroupFootprint: ESXi Host üzerindeki her bir disk grubuna ayrılan bellek miktarı. NumCapacityDisks: Her disk grubundaki kapasite disklerinin sayısı. CAPACITY_DISK_FOOTPRINT: Diskin boyutuna bakılmaksızın kapasite diski başına ayrılan bellek miktarı. DISKGROUP_FIXED_FOOTPRINT: ESXi Host her bir disk grubuna ayrılan sabit bellek miktarı. DISKGROUP_SCALABLE_FOOTPRINT: ESXi host’un fiziksel bellek miktarına bağlı olarak her bir disk grubuna ayrılan bellek miktarı CacheSize: GB cinsinden önbellek diskinin boyutu (SSD için 0-600, hybrid için 0-2TB aralığı) CACHE_DISK_FOOTPRINT: Bellek miktarı önbellek diskinin GB’i başına ayrılır.

All flash için cache diskleri 600GB ile sınırlandırılmıştır. Bu nedenle 600GB’dan büyük SSD’lerin kullanılması ek bellet tüketmez. 800GB’lık disk kullansanızda 600GB cache disk kullanılacağını belirtmek isterim. Bu konu ile ilgili ayrıca zaten bir makale hazırlayacağım. Aşağıdaki örnekte 256 GB sistem memory olduğunu ve her host üzerinde 3 manyetik disk veya all flash olduğunu düşünerek bir hesaplama yapalım.

Örnek 1:

Her host üzerinde 1 disk grup ve hybrid konfigurasyona göre aşağıdaki formülü kullanacağız.

HOST_FOOTPRINT + ( NumDiskGroups * ( DISKGROUP_FIXED_FOOTPRINT + DISKGROUP_SCALABLE_FOOTPRINT + ( CacheSize * CACHE_DISK_FOOTPRINT) + NumCapacityDisks * CAPACITY_DISK_FOOTPRINT)))

7100 + (1610 + 1228 + 600 * 10 + 3 * 180) = 16478 MB

Örnek 2:

Her host üzerinde 3 disk grup ve hybrid konfigurasyona göre aşağıdaki formülü kullanacağız.

HOST_FOOTPRINT + NumDiskGroups * (DISKGROUP_FIXED_FOOTPRINT + DISKGROUP_SCALABLE_FOOTPRINT + CacheSize * CACHE_DISK_FOOTPRINT + NumCapacityDisks * CAPACITY_DISK_FOOTPRINT)

7100 + 3 * (1610 + 1228 + 600 * 10 + 3 * 180) = 35234 MB

Örnek 3:

Her host üzerinde 1 disk grup ve all flash konfigurasyona göre aşağıdaki formülü kullanacağız.

HOST_FOOTPRINT + NumDiskGroups * (DISKGROUP_FIXED_FOOTPRINT + DISKGROUP_SCALABLE_FOOTPRINT + CacheSize * CACHE_DISK_FOOTPRINT + NumCapacityDisks * CAPACITY_DISK_FOOTPRINT)

7100 + (1360 + 1310 + 600 * 20 + 3 * 160) = 22250 MB

Örnek 4:

Her host üzerinde 3 disk grup ve deduplication’in aktif olduğunu düşünürsek aşağıdaki formülü kullanacağız.

HOST_FOOTPRINT + NumDiskGroups * (DISKGROUP_FIXED_FOOTPRINT + DISKGROUP_SCALABLE_FOOTPRINT + CacheSize * CACHE_DISK_FOOTPRINT + NumCapacityDisks * CAPACITY_DISK_FOOTPRINT)

7100 + 3 * (1360 + 120 + 1310 + 600 * 20 + 3 * 160) = 52910 MB

Deduplication için disk grup başına 120MB footprint eklendiğini unutmayın.

Öncelikle şunu belirtmek istiyorum ki yukarıdaki formül işlemleri biraz canınızı sıkabilir ve uğraşmak istemeyebilirsiniz. Bunun için aşağıda belirteceğim excel dosyasını kullanıp gerekli düzenlemeleri yaptıktan sonra tüketeceğiniz memory miktarını öğrenebilirsiniz.

https://docs.google.com/spreadsheets/d/1Gv0NKsZ7C0Wutx4sFTQi66F8K6eMQo9nH6vzr6TcUyI/edit#gid=0

Yukarıda ki hesaplama yöntemi yanlızca All Flash için geçerlidir.  Yukarıdaki tablolarda sadece sarı olan alanları değiştirmeniz sizin için yeterli olacaktır. Böylece tüketilecek memory miktarını görebileceksiniz. Ayrıca aşağıdaki linkten farklı bir hesaplama yöntemine ulaşabilirsiniz.

https://vsanmemory.appspot.com/

VSAN ve Memory Tüketimi

Eğer bir VSAN Cluster’ınız var ise, VSAN’ın tüketmiş olduğu memory miktarınıda görebilirsiniz. Bunun için Cluster’ı seçtikten sonra Monitor > Performance for Support > Performance Dasboard > Memory > VSAN Memory bölümünden VSAN’ın aktif olarak tüketmiş olduğu memory miktarını görebilirsiniz.

Umarım faydalı olmuştur.

İyi çalışmalar.

[tayfundeger]

New Post has been published on

New Post has been published on https://www.tayfundeger.com/vsan-disk-groups.html

VSAN Disk Groups

Merhaba,

VSAN Disk Groups isimli bu yazımda sizlere VSAN ‘ın disk grupları hakkında bilgiler vereceğim. Daha önce VSAN ile ilgili yazmış olduğum yazılara aşağıdaki linkten ulaşabilirsiniz.

https://www.tayfundeger.com/kat/VSAN

VSAN Disk Groups Nedir?

VSAN’i neden kullanıyoruz? Ortamınızda bir storage’iniz yok ise ve storage’in maaliyetleri, yönetim giderleri ile uğraşmak istemiyorsanız VMware’in VSAN çözümü ile cluster’inizda shared bir datastore oluşturabilirsiniz. Böylece vSphere HA, vSphere DRS gibi özellikleride kullanmaya devam edersiniz. Basit olarak VSAN’ı bu şekilde anlatıyorum. VSAN’in en önemli bileşenlerinden birtaneside Disk gruplarıdır. Çünkü bu disk grupları sayesinde bir shared datastore ortaya çıkar.

Daha önceki makalelerimde de anlatmıştım. Bir VSAN Cluster’ında 2 veya 64 ESXi host bulunabilir. Bu sayede hem yüksek compute elde edersiniz hem de kullanılabilir datastore alanı artar. Tabiki VSAN Cluster’ında kaç tane ESXi host olması gerektiği mimari bir karardır 🙂

VMware vSAN‘ın temel bileşenlerinden biri Disk Grubu’dur.

VSAN Disk Grupları sayesinde, VSAN datastore’larının kullanmış olduğu ESXi host üzerinde yer alan diskleri görebilirsiniz. Her ESXİ host, VSAN’a dağıtılmış datastore’ların kullanmış olduğu manyetik diskler veya all flash diskler bulunur. Bunlar sayesinde VSAN datastore’ları oluşur. Disk grupları, cache ve kapasite aygıtları (SSD veya HDD) için SSD’nin ili��kili olduğu bir kapsayıcı gibidir. Disk gruplarına girdiğinizde hangi disk’İn kapasite hangisinin cache olduğunu detaylı olarak görebilirsiniz. Disk grubu bir ESXi host üzerindeki ana depolama birimi diyebiliriz aslında. Her disk grubunda bir SSD ve bir veya birden fazla HDD bulunur. Bu tabi sizin tercih etmiş olduğunuz konfigurasyona göre değişir. All flash ve Hybrid konfigurasyonlar için aşağıdaki linki inceleyebilirsiniz.

VSAN – All Flash ve Hybrid

Bir disk gubunda 7 adete kadar HDD bulunabilir ve bir ESXi host’unda en fazla 5 adet disk grubu bulunur.

Hızlı bir matematik yaparsak, tek bir ESXi host’da vSAN datastore’una depolamaya katkıda bulunan en fazla 40 diskiniz olabilir . İyi bir performans için All Flash konfigurasyonunu kullanmayı unutmayın.

VSAN Disk Groups

VMware vSAN, vSAN’ı etkinleştirdiğinizde tek bir veri deposu oluşturmak için bu disk gruplarını kullanır. Disk gruplarında SSD temel olarak read ve cache görevlerini görürken, HDD kapasite görevini görür. Read ve Write cache ile ilgili aşağıdaki makalemi inceleyebilirsiniz.

VSAN – Read Cache Nedir?

VSAN – Cache Tier

SSD kullanılması performansı arttır. Ancak bunu kullanırken VSAN Cluster mimarisine dikkat etmeniz gerekmektedir. 2 farklı VSAN konfigurasyonu vardır. Bunlar Hybrid ve All Flash konfigurasyonlardır. Bunlar ile ilgili yukarıda bilgi vermiştim.

Hybrid VSAN Cluster’ında 64 adet’a kadar ESXi host olabilir ve her ESXi üzerinde en fazla 5 adet disk grubu bulunabilir. Hybrid VSAN’daki her disk grubunda bir depolama kapasitesi oluşturmak için 1 SSD ve bir veya daha fazla kapasite diski olması gerekir. Maksimum 7 adet kapasite diski kullanılabileceğini unutmayın. Hybrid konfigurasyonda SSD, %70 read, %30 write buffer olarak kullanılır. Böylece hybrid konfigurasyonda performans sağlanır. Manyetik diskler ise tamamen kapasite için kullanılır.

VSAN Disk Groups

All Flash konfigurasyonunu tercih ederseniz 64 adet ESXi host’u kullanabilir ve her ESXi host’da en fazla 5 adet disk grubu kullanabilirsiniz. All flash konfigurasyonda manyetik diskler bulunmaz. All Flash üzerinde bulunan SSD diskler hem kapasite katmanı olarak kullanılırken hem de Write buffer olarak kullanılır. Read cache için SSD’lerin hepsi kullanılır. Dolayısıyla cache için özel bir disk grubu ayırmanıza gerek bulunmaz. Ayrıca her disk grubunda maksimum 7 adet disk bulunduğunuda unutmayın. All flash konfigurasyonlar genellikle daha ağır yüksek IO isteyen ortamlar için kullanılır.

All flash ve Hybrid konfigurasyon ile ilgili aşağıdaki makalemi inceleyebilirsiniz.

VSAN – All Flash ve Hybrid

vSAN  cluster’larında, kapasite aygıtları olan veya olmayan ESXi host’lar bulunabilir. Bu genellikle sorulan bir soru ondan dolayı makale sonunda bu soruya cevap vermek istedim 🙂

Umarım faydalı olmuştur.

İyi çalışmalar.

[tayfundeger]

New Post has been published on VMware Virtualization Blog

New Post has been published on http://www.tayfundeger.com/objective-1-6-describe-and-differentiate-among-vsphere-ha-drs-and-sdrs-functionality.html

Objective 1.6 – Describe and differentiate among vSphere, HA, DRS, and SDRS functionality

Merhaba,

VCP-DCV Study Guide serimizin bu bölümünde vSphere vCenter Server ile birlikte gelen HA, DRS ve Storage DRS kavramlarından bahsedeceğim.

Öncelikle vSphere kavramına bir açıklık getirmek istiyorum. Genellikle vSphere kavramı ve ESXi kavramları farklı yerlerde kullanılır. ESXi Server denildiği zaman standalone çalışan bir hypervisor algılanabilir. vSphere diye bahsedilen aslında tüm ürün gamının ismidir. Buna vCenter Server’da dahildir, VSAN ‘da, ESXi ‘da dahildir. VMware vSphere belirli bir ürün veya yazılım değildir. VMware vSphere, tüm VMware paketinin ticari adıdır. VMware vSphere, sanallaştırma, yönetim ve arayüz katmanları içerir. VMware vSphere’in iki çekirdek bileşeni, ESXi sunucusu ve vCenter Sunucusu’dur. ESXi, sanal makineler ve sanal cihazlar oluşturduğunuz ve çalıştırdığınız hypervisor’dur. vCenter Server, bir ağa bağlı birden fazla ESXi Server ve ESXi Server kaynaklarını bir araya getirdiğiniz hizmettir.

vCenter Server sayesinde merkezi bir yönetim yapabiliyoruz. Merkezi yönetim yapmamızın yanı sıra, size ekstra özelliklerde sağlamaktadır. vCenter Server sayesinde VMware’in en güçlü ve en öne çıkan 3 özelliğini kullanabilirsiniz. Bunlar;

vSphere HA

vSphere DRS

Storage DRS

Elbette vCenter Server ile birlikte gelen bir çok özellik var ancak yukarıda belirttiğim 3 tane özellik oldukça önemli. Bu bölümde bu 3 özellik hakkında çeşitli bilgiler vereceğim.

vSphere HA:

vSphere HA Nedir? vSphere HA Nasıl Çalışır? Bu konular hakkında detaylı bilgi vermeye çalışacağım. Öncelikle şunu belirtmek isterim, ben daha önce vSphere HA ile ilgili bir makale yazmıştım. Bu yazılarıma aşağıdaki linkten ulaşabilirsiniz. vSphere HA yani vSphere High Availability. Biz makalemizde vSphere HA diye bahsedeceğiz.

VMware HA Nasıl Çalışır?

vSphere 6.5 – HA Yenilikleri

.vSphere HA folder

Testing vSphere HA

Ayrıca site içerisindeki arama çubğuna vSphere HA yazarak bu konu ile ilgili yazmış olduğum makalelere ulaşabilirsiniz.

http://www.tayfundeger.com/?s=vsphere+ha

vSphere HA, bir ESXi Server‘in donanım arızası, plansız bir kesinti veya storage’da bir problem olması durumunda sanal makineleri farklı bir host üzerinde restart eder. Hemen bir örnek vermek gerekir ise, vCenter Server tarafından 3 tane ESXİ Server yönetiliyor. Bu 3 tane ESXİ host’un birtanesinin CPU’sunun arızalandığını veya power supply ‘inin arızalandığını düşünelim. Donanım arızası durumunda veya elektrik kesintisi durumunda fiziksel sunucu yani ESXi Server hatayı girmeden düzgün çalışmayacağı için bunun üzerindeki virtul machine’leri farklı bir host üzerinde power on duruma getirir.

VMware vSphere HA, sanal makineler için onları ve içinde bulundukları ESXi Server’ları bir cluster’a toplayarak yüksek kullanılabilirlik yani vSphere HA’i sağlar. VMware cluster’ındaki ESXi host’lar VMware vSphere HA tarafından izlenir ve bir ESXi Server’in arızası durumunda, o ESXi Server sanal makineler cluster’da bulunan alternatif bir ESXi Server üzerinde yeniden başlatılır. vSphere HA sayesinde virtual machine’ler kısa süreli bir kesinti ile tekrar hizmet vermeye devam eder. Belirtildiği gibi, VMware vSphere HA VMware vSphere’in bir parçasıdır ve VMware vCenter Server’in çalıştırırken etkinleştirilir. Ayrıca, vSphere 6.5 ile birlikte gelen Proactive HA özelliğinide etkinleştirdiğiniz takdirde Cluster içerisinde bulunan ESXi Server’ların donanım arızası yaşaması durumunda ESXi Server’i maintenance veya quarantine mode’a alarak donanım arızasını önceden farkederek virtual machine’leri farklı host’lar üzerine migrate edebilir. Proactive HA ile ilgili aşağıdaki makalemi inceleyebilirsiniz.

Proactive HA Nedir? Konfigurasyonu Nasıl Yapılır?

VMware High Availability, kullanmanın belirli gereksinimleri bulunmaktadır. Bu gereksinimlerin en önemlisi ise Shared Datastore’un bulunmasıdır. Yani, cluster içerisinde buluanan ESXi Server’ların hepsi aynı datastore’ları görebilmesi gerekir. Böylece failover anında virtual machine farklı bir ESXi Server üzerinde yeniden başlatılabilecektir. Lisans olarak ise vSphere HA, vCenter Server Standart lisans ile gelmektedir.

vSphere HA ile birlikte isterseniz farklı rule’lar yazabilir ve virtual machine’lerin farklı bir ESXİ Server üzerinde reboot olmasını ayarlayabilirsiniz. Ayrıca Orchestrated restart sayesinde belirli virtual machine’lerin restart olmasını sağlayabilirsiniz.

vSphere HA Orchestrated Restart Nedir?

vSphere DRS:

vSphere DRS sayesinde yük dengelenmesi yapılır. Tam ismi, vSphere Distributed Resource Scheduler‘dir. DRS sayesinde cluster içerisinde bulunan ESXi host’ların CPU, Memory ve Network (Network-Aware DRS) utilization durumları incelenir ve kaynakların yetersiz olduğu ESXi Server üzerindeki virtual machine’ler farklı ESXi Server’lara migrate edilir.

DRS nasıl çalışır?

vSphere 6.5 – DRS Yenilikleri

DRS’in çalışma şekli ile ilgili yukarıdaki gibi bir makale yazmıştım. Buradan ayrıca detaylı bilgi alabilirsiniz. DRS’in farklı mod’u bulunmaktadır. Bunlar;

Manual: Power on halde olan virtual machine’ler için DRS, virtual machine’lerin taşınması için host’ları seçmenizi ister.

Partially Automatic: Power on halde olan virtual machine’ler için DRS, cluster içerisinde bulunan host’ları seçer ve hangi virtual machine’lerin hangi host üzerine taşınacağının önerisinde bulunur.

Fully Automatic: Power on halde olan virtual machine’ler için DRS, taşınacak virtual machine’leri ve hangi host’a taşınacağını otomatik olarak seçer ve taşır.

DRS Gereksinimleri:

Enterprise Plus lisans

Shared datastore

Ayrıca ortamınızda VROPS kullanıyorsanız predictive drs sayesinde virtual machine’lerin yük altında bulunmadan önce migrate olmasını sağlayabilirsiniz. Konu ile ilgili aşağıdaki makalemi inceleyebilirsiniz.

vSphere 6.5 – DRS Yenilikleri

Storage DRS:

Storage DRS’i kullanabilmek için öncelikle Datastore Cluster oluşturmanız gerekmektedir. vCenter Server üzerinde bulunan ESXi Server’lara tanımlı datastore’ları bir cluster altında tutabilirsiniz. Datastore cluster yapmanızın size bazı avantajları olacaktır. vSphere DRS nasıl virtual machine’leri farklı bir ESXi host’a otomatik olarak migrate ediyor ise Storage DRS’de virtual machine’lerin barınmış olduğu datastore’lar I/O ve doluluk oranına göre farklı datastor’lara otomatik olarak migrate olur. Tabi siz bunu isterseniz manual olarakta yapabilirsiniz. Storage DRS kullanabilmeniz için Enterprise veya üstü bir lisans sahip olmanız gerekmektedir.

Yeni bir virtual machine oluşturduğunuzda eğer bir datastore cluster’ınız var ise virtual machine’in barınacağı datastore’u seçmenize gerek bulunmaz. Datastore cluster’ı seçersiniz ve virtual machine en uygun olan datastore’da create edilir. Eğer storage DRS kullanmazsanız datastore utilization oranını manuel olarak takip etmemiz gerekir. Eğer yapınız çok büyük ise zaten bunu yapmakta zorlanabilirsiniz. Storage DRS aynı zaman IO latency takip ettiği için sizin belirlemiş olduğunuz değerler dışına çıkar ise virtual machine’leri otomatik olarak farklı datastore’lara migrate edecektir. Dolayısıyla Storage DRS kullanmanız yapınızın daha sağlıklı çalışmasını sağlayacaktır.

Umarım faydalı olmuştur.

İyi çalışmalar.

[tayfundeger]

New Post has been published on VMware Virtualization Blog

New Post has been published on http://www.tayfundeger.com/objective-1-2-identify-vcenter-high-availability-ha-requirements.html

Objective 1.2 – Identify vCenter high availability (HA) requirements

Merhaba,

Bu bölümde sizlere vCenter Server High Availability yapılandırması ve gereksinimleri ile ilgili bilgi vereceğim. Eğer VCP-DCV almayı düşünüyorsanız bu Study Guide serisini mutlaka ve mutlaka incelemeniz gerekiyor.

vCenter Server Availability ile iglili bilgi vermeden önce, daha önce yazmış olduğum aşağıdaki makaleyi inceleyebilirsiniz. Neden vCenter HA kullanmanız gerekiyor bu konu hakkında kısaca bilgi vermek istiyorum. vCenter HA sayesinde vCenter’ınızın bulunduğu host’un down olması durumunda vCenter Server’da kesinti yaşanmayacak ve passive olan node aktif duruma geçerek hizmet vermeye devam edebileceksiniz. vCenter HA, vCenter Server’in plansız bir şekilde down olmasını önler.

vCenter HA (VCHA) Nedir? Nasıl Enable Edilir?

Ben bu yazımda neden vCenter HA kullanmamız gerekli bunun faydaları nelerdir ve gereksinimleri hakkında bilgi vereceğim.

vCenter Server’in biliyorsunuz 2 farklı kurulum methodu var. Bunlardan birtane Windows Server üzerine vCenter Server kurulumu diğeri ise vCenter Server Appliance ile vCenter Server kurulumu bulunuyor. Bunu zaten bir önceki bölümde anlatmıştım. Ben bu yazımda hem Windows hemde vCenter Server Appliance ile nasıl high availability kullanabilirsiniz onu anlatacağım. İlk olarak vCenter Server Appliance hakkında bilgi vereceğim dah sonrasında Windows failover cluster üzerinde bu işlemlerin nasıl yapılacağını anlatacağım.

vCenter Server Appliance kullanacaksanız vCenter HA kullanmanız oldukça önemlidir.  İlk olarak vCenter Server Appliance üzerinde vCenter HA konfigurasyonu nasıl yapılır, gereksinimleri nelerdir bunlardan bahsedelim.

Bir vCenter HA Cluster‘ı 3 vCenter Server bileşeninden oluşur. Bunlardan birtanesi Active node diğeri passive node bir diğeri ise witness node’dur. vCenter HA’ı enable etmek istediğinizde var olan vCenter Server Appliance üzerinden clone alınır ve passive node oluşturulur. Daha sonrasında otomatik olarak oluşturulan witness node sayesinde hangi node’un down olduğu izlenir. Node’ların her birini farklı bir ESXi host üzerinde tutmak donanım arızasına karşı koruma sağlar. vCenter HA konfigürasyonu tamamlandığında, sadece Active node aktif bir yönetim arayüzüne (ortak IP) sahiptir. vCenter HA’in oluşturuken belirleyeceğinzi private network üzerinden veriler active node’dan passive node’a sürekli olarak kopyalanacaktır.

vCenter HA Node:

Active Node:

vCenter Server Appliance’in çalıştığı, hizmet verdiği node’dur.

Verilerin passive node’a kopyalanması için private bir network kullanır. Buna vCenter HA network’u denir.

Witness node ile iletişim kurması için vCenter HA network’unu kullanır.

Passive Node:

Active node’dan clone alınarak oluşturulmuş bir node’dur.

Active node üzerinde bulunan datalar anlık olarak passive node ile vCenter HA network’u üzerinden kopyalanır.

Active node’un down olması durumunda Passive node kendini aktif duruma getirir.

Witness Node:

Active node’dan clone alınarak oluşturulmuş küçük size’a sahip bir sunucudur.

Hangi node’un down olduğunu takip eder ve hangi node’un passive’den active’e geçeceğine karar verir.

vCenter HA’yı ayarlamadan önce, yeterli bellek, CPU ve datastore kaynaklarına sahip olduğunuzdan emin olun. Ayrıca vCenter HA’yı destekleyen vCenter Server ve ESXi sürümlerini kullandığınızdan emin olun.

Ortamınız aşağıdaki gereksinimleri karşılamalıdır.

ESXi:

ESXi versiyonu 6.0 ve üzeri olmalıdır.

Minimum 3 ESXi host bulunması gerekmektedir.

VMware DRS kullanılması önerilir. Bu durumda en az 3 tane ESXi host bulunması gerekmektedir.

Management vCenter Server:

Eğer Management sunucularınızı bulundurduğunuz bir vCenter Server bulunuyor ise, yani vCenter Server Appliance sunucusu başka bir vCenter Server ortamında bulunuyor ise vCenter HA ‘i yinede kullanabilirsiniz.

vCenter HA için minimum vCenter Server 6.0 veya sonraki sürümler gereklidir.

vCenter Server Appliance:

vCenter Server 6.5 minimum gereklidir.

Deployment size RTO’yu karşılamak için small (4 CPU ve 16GB RAM) konfigurasyon gerekir. Tiny’yi production ortamlarında kullanmayın.

vCenter HA, VMFS, NFS ve vSAN veri depolarıyla desteklenir ve test edilir.

Network Connectivity:

vCenter HA network’unde latency 10ms’den düşük olmalıdır. Active, Passive ve Witness arasında.

vCenter HA network’u management’dan farklı bir subnet’de bulunmalıdır.

Lisans Gereksinimi:

vCenter HA kullanmanız için single vCenter Server lisansına sahip olmanız yeterli olacaktır.

vCenter HA kullanabilmeniz için Standard lisansa sahip olmanız gerekmektedir.

vCenter HA’in 2 farklı deplyment methodu vardır. Bunlardan birtanesi Embedded Platform Services Controller kullanarak deployment yapılması. Diğeri ise External Platform Services Controller kullanarak vCenter HA’in kullanılmasıdır.

Öncelikle şunu belirtmek istiyorum. vSphere 6.7 ‘den sonraki sürümlerde artık external PSC deployment methodu kullanılmayacak. Bundan dolayı production ortamına deployment yaparken bunu dikkate alın lütfen.

External PSC Desteği Bitiyor

vCenter HA ile Embedded Platform Services Controller:

vCenter Server Appliance, embedded Platform Services Controller kullanılarak kurulur.

vCenter Server kurulumu tamamlandıktan sonra ve ESXi host’lar vCenter Server’a eklendikten sonra, vCenter HA sihirbazını kullnarak mevcut vCenter Server’in clone’unu alabilir ve böylece passive ve witness node’lar oluşturabilirsiniz.

vCenter HA sihirbazında otomatik konfigurasyonu seçerseniz clone işlemlerini kendisi yapacaktır. Burada Platform Services Controller’ında tüm servisleri passive node içerisine kopyalanır.

Yapılandırma işlemi tamamlandığında vCenter HA network’u üzerinden active node ile passive node arasında replikasyon gerçekleşir.

vCenter HA ile External Platform Services Controller:

vCenter HA’yı External Platform Services Controller ile birlikte kullanırken, Platform Services Controller ‘ı korumak için harici bir yük dengeleyici (load balancer) kurmalısınız. Bir Platform Services Controller kullanılamaz duruma gelirse, yük dengeleyici (load balancer) vCenter Server Appliance’ı farklı bir node’a yönlendirir.

Not: External PSC’nin desteği bittiğini tekrar hatırlatıyorum. Bu deployment yöntemini sadece study guide için anlatıyorum.

External Platform Services Controller kurulumu aşağıdaki VMware KB’lerinde tartışılmıştır.

2147014: Configuring Netscaler Load Balancer for use with vSphere Platform Services Controller (PSC) 6.5 2147038 : Configuring F5 BIG-IP Load Balancer for use with vSphere Platform Services Controller (PSC) 6.5 2147046 : Configuring NSX Edge Load Balancer for use with vSphere Platform Services Controller (PSC) 6.5

Kullanıcı en az 2 tane external platform services controller kurar.

vCenter Server Appliance Deployment’ı yapılırken kullanıcı External Platform Services Controller’i seçer.

Kullanıcı vCenter Server Appliance ve Platform Services Controller için bir load balancer konfigurasyonu yapar.

vCenter HA yapılandırırken Automatic konfigurasyonu seçerek vCenter Server Appliance’in clone’unu alır, passive ve witness node’lar oluşturulur.

Klonlama işleminin bir parçası olarak, External Platform Services Controller ve load balancer hakkındaki bilgiler de klonlanır.

Yapılandırma tamamlandığında, vCenter Server Appliance, vCenter HA tarafından korunur.

Platform Services Controller kullanılamaz duruma gelirse, load balancer kimlik doğrulama isteklerini veya diğer hizmetleri ikinci Platform Services Controller örneğine yönlendirir.

vCenter HA kurulumu ile ilgili aşağıdaki makalemi inceleyebilirsiniz.

vCenter HA (VCHA) Nedir? Nasıl Enable Edilir?

Microsoft Cluster kullanarak vCenter Server High Availability Yapılandırma:

Not: vSphere 6.7 versiyonundan sonraki major versiyonda Windows vCenter Server kullanılmayacaktır. Bundan dolayı production ortamlarında Windows vCenter Server kurulumu yapmamaya dikkat edin.

vCenter Server 5.5 update 3.x, vCenter Server HA sağlamak için bir seçenek olarak Microsoft Cluster Service’i (MSCS) destekler. Birden fazla vCenter Server örneği bir MSCS kümesindedir, ancak bir seferde yalnızca bir örnek etkindir. vCenter Server patch ya da upgrade’ler hariç, işletim sistemi patch ya da upgrade gibi bakımı yapabilirsiniz. vCenter Server veritabanını kapatmadan cluster’da bulunan bir node’da bakım gerçekleştirirsiniz. Bu yaklaşımın bir başka potansiyel faydası, MSCS’nin bir tür “paylaşılan-olmayan” cluster mimarisi kullanmasıdır. Cluster, birden çok node’dan eşzamanlı disk erişimi içermez. MSCS cluster tipik olarak yalnızca iki node içerir ve cluster’lar arasında paylaşılan bir SCSI bağlantısı kullanırlar. Herhangi bir zamanda yalnızca bir sunucu diske ihtiyaç duyar. Eşzamanlı veri erişimi gerçekleşmez.

vSphere HA cluster seçeneğinin aksine, MSCS seçeneği yalnızca Windows sanal makineleri için çalışır. MSCS seçeneği vCenter Server Appliance desteklemiyor.

Windows vCenter Server High Availability yapılandırması için aşağıdaki adımları izleyebilirsiniz.

OS 2008 R2 veya 2012 R2 ile bir VM oluşturun.

Physical Bus sharing seçeneğinde ayrı bir disk controller’a sahip RDM diskini takın

vCenter kurulumu başlatılmadan önce PSC’yi kurun.

vCenter sunucusunu RDM disklerinden birine kurun ve tüm servisler başlangıç ​​tipini manuel olarak ayarlayın.

VM’yi kapatın ve RDM disklerini çıkarın.

Sanal Makineyi klonlayın ve herhangi bir özelleştirme özelliği seçmeyin ve sysprep kullanmayın.

RDM diskini her iki VM’ye de takın ve açın.

Ana makine adını ve IP adresini VM1’de değiştirin ve her iki node’da failover cluster servisini yükleyin

Failover Cluster kurun ve her iki node’u ekleyin.

Hizmetler için VMware Service Lifecycle Manager ve regedit değerini girin

HKLM\system\CurrentControlSet\Services\VMwareDirectoryService

Role VMware AFD ve VMware vCenter Yapılandırma servislerini ekleyin.

Rolü yeniden başlat.

Umarım faydalı olmuştur.

İyi çalışmalar.

[tayfundeger]

New Post has been published on VMware Virtualization Blog

New Post has been published on http://www.tayfundeger.com/storage-i-o-control-ve-vm-storage-policies.html

Storage I/O Control ve VM Storage Policies

Merhaba,

Bu yazımda sizlere Storage IO Control yani SIOC hakkında bilgiler vereceğim. Storage IO Control aslında çok eski bir özellik olmasına rağmen kullanılmayan özelliklerden birtanesidir. Bu yazımda Storage IO Controller’ın ne işe yaradığını ve ne zaman kullanacağımızı detaylı olarak anlatacağım.

Storage IO Control yani SIOC ilk olarak vSphere 4.1 ile birlikte tanıtıldı. vSphere 4.1 versiyonunda SIOC, Cluster içerisinde bulunan ESXi host’ların üzerinde çalışan virtual machine ‘lerin I/O önceliğini sağlamak için tanıtılmıştır. Evet ilk olarak vSphere 4.1 ile birlikte SIOC duyurusu yapıldı ancak her versiyon ile birlikte sürekli geliştirmeler yapıldı. Hatta vSphere 6.5 sürümü ile birlikte SIOC, VAIO framework kullanılarak tekrar düzenlenmiştir. VAIO terimini ilk defa duymuş olabilirsiniz. vSphere API for IO Filtering‘in kısaltılmasıdır. SIOC sayesinde I/O problemi yaşandığı dönemlerde I/O miktarını kontrol edebilirsiniz. Bir datastore üzerinde SIOC‘u etkinleştirdiğinizde, ESXi bu datastore ile iletişim kurarken latency’i sürekli kontrol eder. Latency belirli bir eşiği aştığında datastore’da performans problemi olduğu kabul edilir ve bu datastore’a erişen tüm virtual machine’lere I/O kaynakları belirlemiş olduğunuz share değerleri ile orantılı olarak dağıtılır. Sahip olduğunuz virtual machine’lerin önemine göre her bir virtual machine veya vmdk için share değeri ayarlayabilirsiniz. Share değeri aslında tüm virtual machine’ler üzerindeki disk bant genişliğini kontrol etmek için girilen temsili bir değerdir. Cluster üzerinde konfigurasyon yapamazsınız. Share değerleri yanlızca ESXi host ile ilgilidir. ESXi host üzerindeki virtual machine’lere atanan share değerlerinin diğer ESXi host üzerinde bulunan virtual machine’lere etkisi yoktur. Shares değeri temsili bir değer olduğu için değeri yüksek olan virtual machine daha yüksek öncelikli kaynak kullanır.

SIOC, Fiber Channel, ISCSI ve NFS datastore‘ları destekler. RDM‘i desteklemez. SIOC’u etkinleştirmek için öncelikle vCenter Server’a login oluyoruz.

vCenter Server‘a login olduktan sonra Storage bölümüne giriyor ve işlem yapacağımız datastore’umuzu seçiyoruz. Daha sonrasında Configure > General > Datastore Capabilities bölümünde edit butonuna basıyoruz.

SIOC‘u etkinleştirdiğinizde default olarak peak throughput değeri %90 için veya latency süresi 30 ms olarak ayarlanmıştır. Bu işlem her 4 saniyede bir kontrol edilir. Şimdi SIOC’u etkinleştirdiğinzde şu soruyu soracaksınız. Ben buradaki değerleri ne olarak belirlemeliyim? Öncelikle şunu söylemem gerekiyor ki burada belireteceğiniz değer sizin virtual machine’lerinizin iş yüküne göre değişkenlik gösterir. Yani her ortamda farklı değerler yazabilirsiniz. Bu tamamen mimarisel bir karardır. Threshold değerlerini düzgün ayarlamaz iseniz virtual machine’lerin performansı olumsuz şekilde etkilenebilir. Burada yüksek bir değer vermeniz datastore’u daha yüksek throughput ile kullanmanızı sağlar. Belirtmiş olduğunuz threshold değerleri aşılmadıkça disklerde herhangi bir kısıtlama olmaz. Eğer throughput, latency’den daha kritikse değeri çok düşük ayarlamamalısınız. Örneğin Fiber Channel diskler için 20ms altındaki bir değer vermeniz throughput ‘u düşürebilir. Çok yüksek bir değer girerseniz 50ms gibi, bu seferde throughput’da çok bir değişme olmaz ancak latency ile karşılaşabilirsiniz. Özet ile burada gireceğiniz değerler hem sizin virtual machine’leriniz üzerindeki iş yükü ile ilgili hemde storage performansınız ile ilgilidir. Bundan dolayı nereye nekadarlık değerler gireceğinizi yanlızca kendiniz bilebilirsiniz.

Eğer ortamda SIOC etkin durumda değil ise ozaman nasıl bir davranış sergilenir?

SIOC etkin durumda değil ise datastore içerisindeki tüm virtual machine’ler kaynak eşit şekilde bölünür. Ancak burada ilk olarak I/O talep eden virtual machine kaynağı öncelikli olarak kullanabilir. SIOC etkin durumda olmadığı için I/O ‘yu datastore düzeyinde düzenleyen hiçbir şey yoktur. SIOC’u etkinleştirdiğinizde mutlaka ve mutlaka disk share değerlerini değiştirmeniz gerekir.

Eğer siz her ESXi host için bu değerleri değiştirmek istemiyor iseniz, vSphere 6.5 ile birlikte Storage IO Control işlemini artık VM Storage Policies üzerinden de ayarlayabileceğiz. Peki Storage Policies ne işe yarıyor biraz bundan bahsedelim. VM Storage Policies sayesinde biz yapımızda bulunan virtual machine’lerin disk değerlerini merkezi bir şekilde yönetebiliyoruz. Örneğin yukarıda disk share değerlerinden bahsetmiştim. VM Storage Policies sayesinde belirlemiş olduğunuz gruptaki virtual machine’lerin share değerlerini toplu halde tanımlayabilirsiniz.

Ben daha önce VSAN ve Storage Policies ile ilgili 2 makale yazmıştım onlarıda inceleyebilrisiniz.

VSAN ve Storage Policies – Bölüm 1

VSAN ve Storage Policies – Bölüm 2

VM Storage Policies ile aşağıdaki değerleri tanımlayabiliyoruz.

IOPS Limit

IOPS Reservation

IOPS Shares

Siz yapınızda bulunan virtual machine’lerin hangi öncelik ile disk kullanacağını, bunların hangisinde IOPS limiti olacağını veya hangisinde IOPS rezervasyonu olacağını kendiniz belirlemelisiniz. Daha sonrasında VM Storage Policies bölümünden ilgili policy’leri oluşturup bunlara virtual machine’leri atayabilirsiniz. Virtual machine’e policy atadığınız zaman, policy’de belirmiş olduğunuz değer artık o virtual machine için geçerli olur.

Bunun için öncelikle, Home > Policies and Profiles > VM Storage Policies bölümüne giriş yapıyoruz. Burada Create VM Storage Policy bölümünden yeni bir Storage Policy oluşturuyoruz.

Yeni bir VM Storage Policy oluşturmak için ilk olarka Policy ismini belirtiyoruz. Description bölümününe isterseniz detaylı açıklama girebilirsiniz. Next ile devam ediyoruz.

Common Rules bölümünde Storage I/O Control bölümü altında default olarak tanımlanmış değerler vardır. Siz burada isterseniz varolan değerleri kullanabilir istersenizde custom değerini kullanıp kendi share değerlerini kendiniz belirleyebilir hatta burada IOPS limit, IOPS reservation, IOPS share değerleride belirtebilirsiniz. Ben burada High IO shares allocation değerini seçiyorum.

High IO shares allocation değerinin özelliklerini gördükten sonra Next ile devam ediyoruz.

Oluşturduğumuz Storage Policy’i tamamlamak için Finish butonunu kullanıyoruz.

Oluşturduğumuz Storage Policy’i bir virtual machine’e eklemek için virtual machine üzerinde sağ click VM Policies > Edit VM Storage Policies seçeneğine giriş yapıyoruz.

Edit VM Storage Policies bölümünde oluşturduğumu Storage Policy’i seçiyoruz ve Apply to all butonuna basıyoruz. Ardından Ok butonuna basarak bu bölümden ayrılıyoruz.

Virtual machine’e storage policy ataması yaptıktan sonra virtual machine’in summary bölümünde yer alan VM Storage Policies bölümünden bu virtual machine’in hangi storage policy’de çalıştığını görebilirsiniz.

Umarım faydalı olmuştur.

İyi çalışmalar.

[tayfundeger]

New Post has been published on VMware Virtualization Blog

New Post has been published on http://www.tayfundeger.com/cluster-quickstart.html

Cluster QuickStart

Merhaba,

vSphere 6.7 Update 1 versiyonu ile birlikte gelen yeniliklerden birtaneside Cluster QuickStart özelliğiydi. Ben bu yazımda Cluster QuickStart hakkında çeşitli bilgiler vereceğim. Cluster QuickStart özelliği vSphere 6.7 Update 1 ile birlikte geldi. Hatta vSphere 6.7 Update 1 yenilikleri hakkında bazı makaleler yazmıştım. Bu yazılarıma aşağıdaki linkten ulaşabilirsiniz.

vCenter Server 6.7 Update 1 Release Oldu!

vSphere 6.7 Update 1 ile Gelen Yenilikler

vSphere 6.7 Update 1 Download Link

vSphere 6.7 Update 1 ile birlikte Cluster QuickStart özelliği geldi. Bu özellik sayesinde bir cluster’ı kolay bir şekilde yapılandırabilirsiniz. Ayrıca mevcut cluster’ınıza yeni ESXi host’lar eklemenize olanak sağlar. VMware ortamlarında genellikle cluster konfigurasyonları manuel olarak yapılır ve manuel olarak işlem yapılması bize zaman kaybı yaşatır. Özellikle vSAN ve distributed switch’in olduğu bir ortamı yapılandırmak birazcık vaktimizi alacaktır. Cluster QuickStart özelliği sayesinde bu işlemleri kısa sürede gerçekleştirebiliyoruz. Cluster QuickStart, cluster konfigurasyonunu belirtmiş olduğunuz ayarlara göre otomatik olarak yapılandırır. Böylece önemli bir ölçüde zamandan tasarruf etmiş olursunuz. VMware Validated Design‘da yer alan önerilere göre cluster konfigurasyonun ayarlandığını belirtmek isterim. Cluster QuickStart’da tüm işlemleri tamamladıktan sonra cluster’ın production ortamında düzgün çalışacağını doğrulamak için bir healthcheck yapar. Bu healthcheck sonucunda eğer bir sorun görülürse sanallaştırma admin’i soruna müdahale eder ve tekrar healthcheck yapabilir.

Cluster QuickStart‘ı kullanabilmeniz için öncelikle bir cluster oluşturmanız gerekiyor. Datacenter üzerinde sağ click New Cluster > Finish butonuna basmanız yeterli olacaktır. Daha sonrasında oluşturduğunuz cluster’ı seçip Configure > QuickStart bölümünden Cluster QuickStart bölümüne ulaşabilirsiniz. Ben Cluster’ı oluştururken makalede göstermek adına vSphere DRS, vSphere HA ve vSAN’ı enable duruma getirdim. Belirtmiş olduğum işlemleri yaptıktan sonra aynı yukarıdaki gibi bir ekran ile karşılaşacaksınız.

Cluster QuickStart özelliği aslında isminden de anlaşılacağı üzere hızlı bir şekilde cluster oluşturmanıza olanak sağlıyor. 3 farklı aşamadan oluşan Cluster QuickStart sayesinde ESXi host’ları tek bir seferde cluster’a dahil edebilirsiniz. Yine Cluster QuickStart wizard’ı sayesinde ESXi host’ların lockdown mode ve NTP’lerini ayarlayabilirsiniz. Normalde bu işlemleri yapmak için tek tek ESXi host’lar üzerinde işlem yapmak gerekiyor.

Cluster QuickStart’ın 3 aşamadan oluştuğunu söylemiştim. Ben burada 2 numaralı aşama olan Add Host bölümünden Add butonuna basıyorum ve yukarıdaki gibi bir ekran ile karşılaşıyorum. Burada hali hazırda vCenter Server’a ekli ESXi host’larım olduğu için Existing hosts bölümünden ESXi host’ları seçiyorum ve Next butonu ile ilerliyorum. Eğer ESXi host’larım bir vCenter Server altında olmasaydı New host bölümünden ESXi host’larımızı manuel olarak ekleyebilirdik.

Host summary bölümünde ESXi host’ların genel olarak biglilerini görüyoruz. Next ile devam ediyoruz.

Ready to complete bölümünde ise seçmiş olduğumuz ESXi host’lar artık cluster altına alınacağı bilgisi verilmektedir. Eğer ESXi host’lar maintenance mode’da değil ise otomatik olarak maintenance mode’a alınacaktır. Bu aşamada ESXi host’lar üzerinde herhangi bir virtual machine’in olmadığına dikkat etmelisiniz. Finish butonu ile işlemi sonlandırıyoruz.

Gördüğünüz gibi ESXi host’lar cluster altına eklendi ve QuickStart’ın 2. adımı olan add host bölümünde gerekli doğrulama işlemleri yapıldı. Son aşamada isterseniz Configure Cluster bölümünden vMotion, Management trafiği ve vSAN konfigurasyonunu gerçekleştirebilirsiniz.

Configure Cluster bölümüne girdiğinizde isterseniz cluster’a dahil olan ESXi host’ları distributed switch’e ekleyebilir hatta burada vMotion ve vSAN network’lerini birbirinden ayırabilirsiniz.

Oluşturduğunuz distributed switch’lerde port group’lar oluşturabilir bu port group’ları VSAN veya vMotion network’u için kullanabilirsiniz. Bu tamamen sizin mimarinize kalmış bir durum aslında. Sonraki aşamalarda vMotion ve vSAN trafiği için IP adreslerini belirtebilirsiniz. Hatta isterseniz DHCP’de bırakabilir veya static IP’de kullanabilirsiniz. Burada Autofill seçeneğini kullanarak otomatik olarak IP, subnet gibi bilgileri doldurtabilirisniz.

Oluşturduğunuz distributed switch’lere hangi uplink’lerin bağlanacağını da yine bu adımlardan belirtebilirsiniz.

Ek olarak;

Cluster QuickStart, VMware vSphere Network I/O Control‘u otomatik olarak aktif eder ve yapılandırır. Yukarıdaki resimde de göreceğiniz üzere trafik türlerini ve bu trafik türlerinin share değerlerini görebilirisniz. Network’de bir kaynak darboğazı yaşandığında hangi trafiğe öncelik verilmesini share değerlerinden belirtebilirsiniz.

Cluster QuickStart’ın en güzel bölümlerinden biri aslında. Advanced options altından vSphere HA, vSphere DRS ve vSAN için özel konfigurasyonlar yapabilirsiniz. Örneğin, vSAN için stretched clsuter konfigurasyonu yapabilir, deduplication ve compression’u enable duruma getirebilir ve fault domain konfigurasyonunu yapabilirsiniz. Bu cluster altındaki tüm ESXi host’ların NTP’lerini aynı anda güncelleyebilir ve ESXi host’ları tek tek konfigure etmeden NTP’leri tanımlamış olursunuz. Tabi buradan EVC’ninde yapılandırıldığını belirtmek isterim.

Yazımın en başındada belirttiğim gibi yapmış olduğumuz işlemler VMware Validated Design‘da yer alan öneriler ile karşılaştırılır ve production ortamı için uygunluğu kontrol edilir.

Cluster QuickStart’ı vSAN’ı kullanmayacağınız bir ortamda cluster’ınızı yapılandırmak için kullanacağınızı pek sanmıyorum. Eğer ortamınızada distributed switch vs yok ise zaten kullanmanızın bir amacıda bulunmuyor. Manuel olarakta işlemleri yapabilirsiniz. Cluster QuickStart’ın asıl amacı vSAN kullanılan ortamlarda daha hızlı konfigurasyon yapılmasını sağlıyor. HCI cluster’ını hazırlamak için elbette script’de kullanabilirsiniz ancak script’i her versiyonda çalıştıramayabilirsiniz. Tamda burada işte Cluster QuickStart büyük bir önem kazanıyor.

https://www.vmware.com/solutions/software-defined-datacenter/validated-designs.html

Umarım faydalı olmuştur.

İyi çalışmalar.

[tayfundeger]

New Post has been published on VMware Virtualization Blog

New Post has been published on http://www.tayfundeger.com/vsphere-platinum-nedir.html

vSphere Platinum Nedir?

Merhaba,

Bir önceki yazımda sizlere vSphere 6.7 Update 1 ‘in yeniliklerinden bahsetmiştim. Hatta bu makalemin en sonunda sizlere vSphere Platinum‘dan bahsetmiştim. vSphere Platinum detaylı bir konu olduğu için ayrı bir makalede bilgi vermek istedim. vSphere 6.7 Update 1 yenilikleri ile ilgili yazmış olduğum makaleye aşağıdaki linkten ulaşabilirsiniz.

vSphere 6.7 Update 1 ile Gelen Yenilikler

vSphere 6.7 update 1 ‘in duyurusu ile birlikte VMware vSphere Platinum‘unda duyurusu yapıldı. Ürünün kasım ayı içerisinde çıkarılması beklendiğinide belirtmek isterim.

Kullanmış olduğumuz alt yapıda yani VMware altyapısında birden fazla virtual machine ve bunların üzerlerinde çeşitli uygulamalar çalıştığı için bunların güvenliğini sağlamakta önemli bir durum haline geldi. Nihayetinde tüm dünyada bir dijital dönüşüm çağı başlamış durumda ve şirketler gelirlerini artırmak için ve piyasada farklılaşmak için dijital dönüşüme biraz daha önem vermeye başlamış durumda. Tabi bu dijital dönüşümün önemli bir basamağıda güvenliktir. Uygulamalarınızı çalıştırdığınız platformun güvenliği çok önemlidir. Altyapı oluşturulurken bunun güvenlik boyutunuda ele almak ve bunu güvence altına almak gerekmektedir. Günümüzde güvenlik tehditleri git gide artmaktadır ve daha karmaşık bir hal almaktadır. Güvenlik denildiğinde ilk olarak aklınıza antivirus geliyor ancak antivirus bazı durumlarda etkisiz olabiliyor. Ayrıca antivirus’un bulunduğu işletim sisteminde çok fazla kaynak tüketiminine sebep olup sistem performansını olumsuz etkileyebilir. Bazı durumlarda ise antivirus bir saldırıyı veya atak’ı çok geç farkedebiliyor.

Güvenlik tehditleri günümüzde bir hayli artmış durumda. Bunun için sizlere VMware vSphere Platinum hakkında bilgi vermek istiyorum. vSphere Platinum, VMware vSphere Enterprise Plus ve VMware AppDefense‘yi içeren yeni bir paketdir . Ancak bu sadece iki VMware ürününden oluşan bir paket değildir. vSphere Platinum, vSphere Platinum için özel olarak tasarlanmış özel bir vCenter Server plugin‘i içerir ve bu iki ürün arasında bir entegrasyon oluşturur. Bu eklenti VMware ortamını yöneten admin’lere, AppDefense’in uygulama katmanında güvenlik tehditlerinin görünürlüğü sağlar ve daha güvenli bir altyapı sağlamak için Güvenlik Yöneticileriyle yakın işbirliği içinde çalışmasına olanak tanır.

VMware vSphere Platinum, hypervisor’e tam olarak entegre edilmiş gelişmiş güvenlik yetenekleri sunan yeni bir vSphere sürümüdür. Bu yeni sürüm, AppDefense ürünü ile bir araya getirerek uygulamaların güvenliği sağlar. VMware, AppDefense ürününü ilk olarak VMworld 2017’de duyurmuştu.

Yukarıda VMware AppDefense‘in arayüzünü görebilirsiniz. Ancak burada dikkat ettiyseniz virtual machine’ler gösterilmiyor. İlgili virtual machine’ler çeşitli gruplar halinde gösteriliyor. Elbette burada virtual machine bazında sorunun ne olduğunuda kısmen inceleyebilirsiniz ancak VMware ortamını yöneten kullanıcılar için bu oldukça zor bir durum. Yani şöyle düşünün virtual machine içerisinde hangi uygulamanın veya hangi serviste bir problem olduğunu doğrudan bu ekrandan kontrol etmeniz sizin zamanınızı alacaktır.

Yukarıdaki ekran görüntüsünde sanal altyapı nesnelerine daha çok odaklanmış bir gösterge panosunu görebilirsiniz: ESXi host‘lar ve virtual machine’ler. Bu, vSphere Administrator ürününün tehditleri izlemesi ve ele alması için daha kolay bir yöntemdir çünkü bu, yöneticinin bu tehditleri IP adresleri veya bağlantı noktaları yerine yönetilen nesnelerle hızlı bir şekilde ilişkilendirmesine olanak tanır. Aslında buradaki ekranı VROPS’un monitor göstergelerine benzetebilirsiniz. Bende açıkcası ona benzettim. Yukarıdaki ekranda örneğin alt yapınızda bulunan virtual machine’lerin kaçtanesi unsupported durumd aolduğunu veya kaçtanesi appdefense tarafından izlendiğini görebilirsiniz. Yine altyapınızda bulunan virtual machine’ler üzerindeki servislerin risk durumlarını görebilirsiniz. Farkı biraz daha anlatabildim diye düşünüyorum.

Örneğin yukarıdaki ekran görüntüsünde host and cluster tab’ından monitor bölümüne girişi yapılmış. Yine burada yer alan AppDefense tab’ı altında yer alan Processes bölümünden bu virtual machine üzerinde yer alan processes’lerin ayrıntılarını görebilirsiniz. Dikkat ettiyseniz burada skor’larda yer almaktadır. Yani bu processes güvenli mi yoksa güvensiz mi buradan görebilir hatta bunun path’inide görebilirsiniz.

Ayrıca vSphere Platinum’un VSAN, NSX ve vRealize Suite gibi ürünler ile de tam entegrasyonunun olduğunu belirtmek isterim.

vSphere Platinum oldukça dikkat çekeceğe benziyor. Ürün daha release olmadığı için şuan için makalesini yazamıyorum ancak release olduktan sonra hemen inceleme ve kurulum makalesini yazacağım. Orada daha detaylı olarak anlatıyor olacağım.

Ürün ile detaylı bilgiye aşağıdaki link’den ulaşabilirsiniz.

https://blogs.vmware.com/vsphere/2018/08/under-the-hood-vsphere-platinum.html

Umarım faydalı olmuştur.

İyi çalışmalar.

[tayfundeger]

New Post has been published on VMware Virtualization Blog

New Post has been published on http://www.tayfundeger.com/vsan-iscsi-target-konfigurasyonu.html

VSAN - ISCSI Target Konfigurasyonu

Merhaba,

VSAN 6.5 ile birlikte gelen yeniliklerden birtaneside ISCSI target idi. VSAN 6.5 ile birlikte artık VSAN üzerinde bulunan disk’leri ISCSI servisi sayesinde başka sunuculara tanımlayabiliyoruz. Yani VSAN ISCSI Target Service sayesinde block stsorage gibi kullanabiliyoruz. Tabi bunun şuanda limitasyonları mevcut ancak ilerleyen dönemlerde bu limitasyonlarda ortadan kalkacaktır diye düşünüyorum. VSAN 6.5 relase olduğu anda bunu yazamadım oyüzden şimdi yazmak kısmet oldu 🙂 VSAN 6.6’da bu özellik halen bulunuyor bu arada.

VSAN kullanıyorsanız üzerindeki ISCSI Servisini kullanmanızın size bazı faydaları olabilir. Bunları kısaca bahsedecek olursak;

Oracle RAC deployment’ında vmdk’ları map etmek için kullanabilirsiniz.

VSAN kaynaklarını fiziksel sunucular ile paylaşabilirsiniz.

CHAP ve Mutual CHAP Authentication support’u bulunmaktadır.

ISCSI Target, storage policy tarafından korunmaktadır.

vCenter/RVC/Observer üzerinden basit bir şekilde storage management’ı yapabilirsiniz.

Limitasyonları:

Şuan için Microsoft Cluster implementasyonu desteklenmiyor.

Diğer vSphere host’ları target olarak kullanmak support edilmiyor.

3 party hypervisor’ler tarafından support edilmiyor.

Virtual machine’lerde kullanımı support edilmiyor.

Configuration Maximums:

VSAN Cluster başına maksimum 1024 LUN

VSAN Cluster başına maximum 128 Target

Target başına maksimum 256 LUN

Maksimum lun boyutu 62TB

Host başına maksimum 128 iscsi session

Host başına maksimum 4096 ISCSI IO queue depth

LUN başına maksimum 64 initiator

Not: VSAN ISCSI özelliğini kullanarak ESXi, 3 party hypervisor ‘a datastore veya RDM olarak bir virtual machine’e disk eklenilmesi şuanda support edilmiyor.

İlerleyen versiyonlarda daha farklı özelliklerinden faydalanabileceğiz.

VSAN ISCSI servisini enable duruma getirmeden önce ISCSI data’larının hangi network üzerinden geçeceğini belirtmemiz gerekiyor. İsterseniz management üzerinden bu data’yı gönderebilirsiniz ancak yoğun bir trafiğe sebep olacaktır. Bunun için ayrı bir network belirlemenizde fayda var.

VSAN cluster’ında bulunan host’larda ISCSI için ayrı bir network oluşturuyoruz.

Ben tek bir vSwitch içerisinde yeni bir portgroup oluşturdum. Siz isterseniz ayrı bir virtual switch oluşturup ayrı bir uplink bağlayıpda yapabilirsiniz. Zaten doğrusuda budur. ISCSI network’u maangement network’u etkilememesi için ayrı bir switch üzerinde portgroup oluşturulması gerekir. Ben lab ortamında bu şekilde devam ediyorum. Yukarıda ISCSI portgroup’unu görebilirsiniz.

VSAN ISCSI Target Service‘i enable duruma getirmek için VSAN cluster’ını seçiyorum daha sonra Configure > vSAN > General bölümüne giriş yapıyorum. Burada vSAN ISCSI Target Service bölümünde yer alan Edit butonuna basıyorum.

Karşımıza açılan pencerede Enable vSAN ISCSI target service seçeneğine basıyoruz. Burada Default ISCSI network bölümünden oluşturmuş olduğunu ISCSI network’unu seçmeniz gerekiyor. Benim oluşturduğum network vmk2. Vmkernel adapters bölümüne giriş yaptığınızda Device bölümünden network’unuzun ismini görebilirsiniz. Eğer ISCSI Target’da bir authentication method kullanmak istiyorsanız Default authentication bölümünden bunu belirtebilirsiniz. Ayrıca ISCSI Target’ı bir storage policy ile ilişkilendirebilirsiniz. OK butonuna basıyoruz.

ISCSI Target Service enable duruma geldi. Artık yeni bir ISCSI Target ekleyebiliriz. Bunun için Configure > vSAN > ISCSI Target bölümüne giriş yapıyoruz. Daha sonra burada yer alan + butonuna basıyoruz.

Karşımıza açılan pencerede aşağıdaki alanları dolduruyoruz.

IQN: Default olarak verilmektedir.

Alias: ISCSI’nin VSAN üzerinden bağlandığını anlamak için VSAN yazdım.

Storage Policy: VSAN üzerinde oluşturduğunuz ISCSI target bir storage policy tarafından yönetilir. Siz isterseniz burada kendi policy’nizi seçebilirsiniz. Default olarak Virtual SAN Default Storage Policy gelmektedir.

Network: ISCSI’nin kullanmasını istediği network’u seçiyoruz.

TCP Port: Default ISCSI port’u 3260’dır. Aynen bırakıyoruz.

Authentication: ISCSI’nin başka bir sunucu tarafından görülmesini istemiyorsanız Authentication bölümünden CHAP doğrulaması yapmanız gerekiyor. Ben böyle birşey istemediğim için None olarak bırakıyorum.

Oluşturacağımız ISCSI target‘a ilk LUN’u eklemek için Add your first LUN to the ISCSI Target seçeneğini seçmemiz gerekiyor. Bu seçeneği seçince;

LUN ID: Default olarak bırakabilirsiniz. Her lun ekleme esnasında burası otomatik değişecektir.

Alias: Hangi sunucuya tanımlayacak iseniz bu LUN’u onun ismini yazabilirsiniz. Ben Active Directory sunucunusuna tanımlayacağım için AD yazdım.

Storage Policy: Mevcut Storage policy’inizi seçebilir veya default olarak bırakabilirsiniz.

Size: Bu LUN’un kaç GB boyutunda olmasını istiyorsanız onu yazmalısınız.

Tüm işlemleri tamamladıktan sonra OK butonu ile çıkıyoruz.

Son durumda ISCSI disk’imiz aktif durumdadır. Artık bu ISCSI bağlantısını bir sunucuya gösterebiliriz.

Windows sunucuma giriş yapıyorum ve ISCSI Initiator’u açıyorum. Burada Target IP’mizi yazıyoruz. ESXi host’a vermiş olduğunuz VMkernel port’un IP’sini yazabilirsinz.

Discovery bölümüne geldiğinizde ISCSI Target’in çalıştığını görebilrisiniz. vsan-n2-65 üzerinden şuanda bağlı durumda.

Disk management bölümüne giriş yaptığınızda ISCSI olarak tanımladığımız 5GB’lık disk’in geldiğini görebilirsiniz.

VSAN üzerinde kullanılan ISCSI Target şuanda windows sunucularda unsupported durumdadır. Ben makalede kolay birşekilde anlaşılır olması için bu şekilde anlattım.

Umarım faydalı olmuştur.

İyi çalışmalar.

[tayfundeger]

New Post has been published on VMware Virtualization Blog

New Post has been published on http://www.tayfundeger.com/vsan-upgrade-prerequisite.html

VSAN Upgrade Prerequisite

Merhaba,

VSAN ‘ı upgrade etmeden önce belirli gereksinimleri karşılamanız gerekiyor ve belirli kontrolleri yapmanız gerekiyor. Upgrade sırasında veya sonrasında oluşabilecek sorunlara karşı kontrolleri sağlamalıyız. Bunun için VSAN’ı upgrade etmeden önce ortamınızın vSphere donanım ve yazılım gereksinimlerini karşıladığından emin olun.

VSAN sürekli gelişiyor ve her yeni sürümde gelen farklı özellikler sayesinde VSAN’ı upgrade etmemiz gerekiyor. VSAN doğrudan hypervisor üzerinde çalıştığı için upgrade sırasında belirli aşamalara dikkat etmemiz gerekiyor. Özellikle ESXi‘in çalıştığı hypervisor’un donanımı burada çok önemli. Mevcut VSAN sürümünde uyumlu olan driver ve firmware’ler VSAN’ın upgrade’i ile uyumsuz duruma gelebiliyor. Burada VSAN upgrade’inda hangi aşamalara dikkat edilmesi gerektiği konusunda çeşitli bilgiler vereceğim.

Daha önce yazmış olduğum VSAN ile ilgili makaleler aşağıdaki link’den ulaşabilirsiniz.

http://www.tayfundeger.com/kat/VSAN

Software, hardware, drivers, firmware, ve storage I/O controller:

Upgrade sonrasında VSAN sürümü yükseleceği için mevcut donanımınız üzerinde bulunan driver, firmware, Storage IO controller’ların Virtual SAN tarafından desteklenip desteklenmediğinden emin olun. Bunun için aşağıdaki link’deki adrese giderek VMware HCL üzerinden donanımın support edildiğinden emin olmalısınız.

http://www.vmware.com/resources/compatibility/search.php

Virtual SAN version:

Virtual SAN’ın en son sürümünü kullandığınızdan emin olun. Hala bir beta sürümünü kullanıyorsanız upgrade’iniz başarısızlıkla sonuçlanacaktır.

Disk space:

VSAN upgrade’inin tamamlanması için yeterli alana sahip olduğunuzdan emin olun. vCenter Server kurulumu için gereken disk depolama miktarı, vCenter Server yapılandırmanıza bağlıdır. vSphere ‘i upgrade etmek için gerkeen disk alanı ile ilgili bilgiler için vSphere Upgrade dökümanlarını inceleyebilirsiniz.

Virtual SAN disk format:

Disk format’ını upgrade etmek için yeterli kapasiteye sahip olduğunuzdan emin olmalısınız. En büyük disk grubunun tüketilen kapasitesine eşit boş alana sahip değilseniz, bu alan, dönüştürülmekte olan disk grupları dışındaki disk gruplarında bulunuyorsa, migration olarak Allow reduced redundancy seçeneğini tercih etmeniz gerekir. Karışık bir cümle olduğunu düşünüyorum bunun için bir örnek vereceğim.

Örneğin, bir cluster’daki en büyük disk grubunun fiziksel kapasitesi 10 TB’tır ancak yalnızca 5 TB tüketilir. Migrate olan disk grupları hariç olmak üzere, cluster’ın herhangi bir yerinde ilave 5 TB spare kapasiteye ihtiyaç duyulacaktır. Virtual SAN disk formatını upgrade ederken, host’un maintenance mode’da olmadığından emin olun. Bir Virtual SAN cluster’ının herhangi bir üyesi maintenance mode’a girdiğinde, host artık cluster’a storage alanı eklemez ve host kapasitesi veri için kullanılamadığı için, cluster kapasitesi otomatik olarak azaltılır. Maintenance mode ile ilgili aşağıdaki makalemi inceleyebilirsiniz.

VSAN 6 Maintenance işlemi nasıl yapılır?

Virtual SAN hosts:

Virtual SAN host’larının maintenance mode’una geçirdiğinizi doğrulayın ve Ensure data accessibility veya Evacuate all data seçeneğini işaretleyin.

Upgrade işlemini otomatikleştirmek ve test etmek için vSphere Update Manager’i kullanabilirsiniz. Bununla birlikte, Virtual SAN’ı upgrade etmek için vSphere Update Manager’i kullandığınızda, varsayılan evacuation mode Ensure data accessibility’dir. Ensure data accessibility mode kullandığınızda, verileriniz tamamen korunmaz ve Virtual SAN’ı upgrade ederken bir arıza ile karşılaşırsanız, beklenmedik bir veri kaybına uğrayabilirsiniz. Bununla birlikte, tüm data’ları cluster’da başka bir host’a migrate etmenize gerek olmadığından, Ensure data accessibility mode, Evacuate all data mode daha hızlıdır.

Virtual Machine:

Her ihtimale karşı VSAN cluster’ında bulunan tüm virtual machine’lerin backup’larını almayı unutmayın. Böylece virtual machine’lere zarar gelme durumunda backup’dan restore yapabilirsiniz.

Öneriler:

Virtual SAN ile kullanılack ESXi host’larda aşağıdaki seçenekleri göz önünde bulundurmalısınız.

ESXi ana bilgisayarları 512 GB veya daha az bellek kapasitesine sahipse, yükleme ortamı olarak SATADOM, SD, USB veya sabit disk aygıtları kullanın.

ESXi ana bilgisayarları 512 GB’den yüksek bellek kapasitesiyle yapılandırılmışsa, yükleme aygıtı olarak ayrı bir manyetik disk veya flaş aygıtı kullanın. Ayrı bir aygıt kullanıyorsanız, Sanal SAN’ın aygıta hak talebinde bulunmadığından emin olun.

Bir SATADOM aygıtından bir Sanal SAN ana bilgisayar önyükleme yaparken, single level cell (SLC) aygıt kullanmalısınız ve önyükleme aygıtının boyutu en az 16 GB olmalıdır.

Sanal SAN 6.5 ve sonraki sürümleri, bir Sanal SAN kümesindeki bir ESXI ana bilgisayarının önyükleme boyutu gereksinimlerini ayarlamanızı sağlar. Daha fazla bilgi için http://kb.vmware.com/kb/2147881 adresindeki VMware bilgi bankası makalesine bakın.

vCenter Server Upgrade:

Virtual SAN upgrade’ı sırasında ilk olarak yapılacak işlem, vCenter Server ve ESXi server’in upgrade işlemidir. İlk olarak vCenter Server upgrade’i yapılmalıdır. VMware, vCenter Server 4.x, vCenter Server 5.0.x, vCenter Server 5.1.x ve vCenter Server 5.5’ten 64-bit sistemlerdeki in-place upgrade’leri vCenter Server 6.0 ve sonrasına desteklemektedir. VCenter Server upgrade’i, bir database schema upgrade’i ve vCenter Server’ın upgrade’ini içerir.

ESXi Server Upgrade:

vCenter Server’ı yükselttikten sonra, Virtual SAN cluster’inin upgrade’i için bir sonraki görev ESXi host upgrade’inin yapılmalısıdır. Virtual SAN cluster’ında birden fazla host’unuz varsa ve host’ları upgrade etmek için vSphere Update Manager’i kullanırsanız, default evacuation mode Ensure data accessibility olarak gelir. Bu modu kullanırsanız ve Virtual SAN’i upgrade ederken bir arıza yaşarsanız, data’larınız risk altındadır.

Umarım faydalı olmuştur.

İyi çalışmalar.

[tayfundeger]

New Post has been published on VMware Virtualization Blog

New Post has been published on http://www.tayfundeger.com/vsan-witness-appliance-nedir-ne-is-yapar.html

VSAN - Witness Appliance Nedir? Ne iş Yapar?

Merhaba,

Standart bir VSAN kurulumunu ve upgrade’ini daha önce blog’um üzerinde belirtmiştim. Eğer 2 node’lu bir VSAN veya Stretched Cluster ortamı kullanmak istiyorsanız bunun Witness Appliance kullanmanız gerekmektedir. Bu yazımda Witness Appliance’in ne iş yaptığını detaylı olarak anlatacağım.

Witness Appliance, ilk olarak VSAN 6.1 ile duyuruldu. Yani VMworld 2015’de açıklandı. VSAN 6.1 ile birlikte 2 yeni özellik gelmişti. Birincisi, VSAN 6.1 ile birlikte artık VSAN üzerinde bulunan virtual machine’lerimizi datacenter’lar arasında koruyabiliyoruz. Tabi bu işlem için Stretched Cluster oluşturmamız gerekiyor. VSAN Stretched Cluster ile ilgili detaylı bilgiyi aşağıdaki link’de bulabilirsiniz.  İkincisi ise 2 node’lu VSAN oluşturmamıza olanak sağlayan bir yapılandırma support edilmiştir. 2 node’lu VSAN, remote office/branch office için harika bir çözüm. Ancak yukarıda bahsetmiş olduğum 2 yapılandırma içinde dedicated bir witness host’a ihtiyaç bulunmaktadır. İşte Witness Appliance’da tam burada devreye giriyor.

VSAN Stretched Cluster

Witness Appliance diye bahsedildiği anda herkesin aklında farklı birşeyler oluşuyor ancak durum tam olarak tahmin ettiğiniz gibi değil. Stretched Cluster ve 2 node’lu VSAN oluşturabilmek için witness host kullanmamız şart durumda. Witness Appliance diye bahsedilen ürün aslında bir ESXi. .OVA formatında hazır paketlenmiş bu dosyayı deploy ettiğinizde standart bir ESXi ortaya çıkar. Ancak bu ESXi üzerinde ne bir virtual machine bulunur ne de HA ve DRS gibi konfigurasyonlar enable durumdadır. Tamamen yalın bir şekilde çalışan bir ESXi. Bunun amacı ise problem anında yani bir down durumunda hangi site’in aktif olacağına karar vermesidir. Üzerinde sadece VSAN cluster’ının metadatası bulunur.

Witness apppliance yerine siz fiziksel bir donanımda kullanabilirsiniz ancak bu size ekstra bir lisans maaliyeti çıkaracaktır. Bundan dolayı VMware ‘de Witness Appliance’i release etmiştir. Yani virtual machine içinde çalışan bir ESXi. Ayrıca fiziksel bir donanımı komple witness için ayırmak çok doğru birşey değil. Yani lisans gereksinimlerini karşılasanız bile, witness üzerinde bir performans ihtiyacı olmayacağı için fiziksel bir donanımı bu iş için ayırmak oldukça mantıksız duruyor. Witness appliance’i deploy ederken 3. bir site olarak deploy etmeniz gerekiyor. Yani varolan cluster dışında tutmanız gerekiyor. Stretched cluster 2 site ve 1 witness host’dan oluşur. Witness host 3. site’da bulunur ve virtual machine’lerin witness bilgilerini bulundurur. Witness host üzerinde yukarıda belirttiğim gibi sadece metadata’lar bulunur ancak witness host storage operasyonlarında bulunmaz. Yani Witness host üzerinde bulunan disk’ler VSAN üzerinde kullanımda değildir. Witness host, 2 site arasında network bağlantısı kesildiğinde datastore component’lerinin kullanılabilirliği konusunda karar veren önemli bir bileşendir. 2 site arasında network bağlantısının gittiği durumda witness host tercih etmiş olduğu site ile yeni bir Virtual SAN cluster’ı oluşturur. Diğer site tekrar up olduğunda tüm verilerin en son kopyalarına sahip olmasını sağlamak için senkronizasyon başlatılır.

Witness host eğer fail olursa buna bağlı tüm objeler noncompliant duruma gelir ancak herhangi bir erişilmezlik durumu oluşmaz.

Witness host’un bazı özellikleri şunlardır:

Witness host’un, düşük bandwidth tüketimi bulunur.

Witness host üzerinde virtual machine çalıştırmaz.

Tek bir Witness host yanlızca bir Virtual SAN Stretched Cluster’ını support eder.

Witness host üzerinde mutlaka birtane VMkernel poert’u bulunmalıdır. Bu port üzerinde Virtual SAN Traffic enable duruma getirilmelidir. Witness host, management ve Virtual SAN Traffic’i için tek bir adapter kullanabilir. İsterseniz Virtual SAN Traffic’i için dedicated bir port kullanabilirsiniz.

Witness host, stretched cluster’dan bağımsız olmalıdır. Başka bir cluster’a eklenemez veya vCenter Server üzerinden başka bir yapıya taşınamaz.

Witness host için oluşturmak için Witness Appliance’i kullanabilirsiniz. Ancak isterseniz fiziksel bir host’uda bunun için ayrabilirsiniz.

Witness Appliance’i aşağıdaki adresten download edebilirsiniz.

https://my.vmware.com/web/vmware/details?downloadGroup=WITNESS_OVA_62&productId=564

Umarım faydalı olmuştur.

İyi çalışmalar.