#vmware cluster yapılandırma

[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 https://www.tayfundeger.com/vsphere-cluster-services.html

vSphere Cluster Services

Merhaba,

vSphere Cluster Services isimli bu yazımda sizlere vSphere 7.0 U1 ile birlikte gelen vCLS yani vSphere Cluster Services hakkında bilgi vereceğim. Daha önce vSphere 7.0 ile ilgili yazmış olduğum yazılara aşağıdaki linkten ulaşabilirsiniz.

https://www.tayfundeger.com/?s=vsphere+7

vSphere 7.0 Update 1 ‘den itibaren vSphere Cluster Services default olarak etkin durumdadır. Peki vSphere Cluster Services Nedir? vSphere 7.0 Update 1 ile birlikte vSphere Cluster Services, mevcut cluster’ınıza bağlı olarak çalışan bir servistir. vCenter Server’in down olması durumunda, DRS ve HA gibi hizmetlerin çalışması ve kullanılabilirliğinde sorunlar olacaktır. Elbette siz vCenter Server’i VCHA kullanabilirsiniz. Ancak her ortamda, her kullanıcı VCHA kullanmayı tercih etmeyebilir. Bundan dolayı vSphere 7.0 U1 ile birlikte vSphere Cluster Services isimli bir özellik tanıtıldı.

vSphere Cluster Services

vSphere Cluster Services sayesinde, Cluster üzerinde bulunan ESXi host’larda vCLS VM’ler oluşturulur. Bir Cluster içerisinde maksimum 3 adet vCLS VM oluşur. Sizin sahip olduğunuz cluster’da 1 host veya 2 host var ise yine vCLS etkinleştirilir. Ancak her cluster’da maksimum 3 adet vCLS VM ‘in oluşacağından unutmayın. Eğer sizin 1 tane ESXi host’unuz var ise 1 tane VM oluşuyor. 2 adet ESXi host var ise 2 adet VM oluşuyor. Son olarak 3 ESXi host veya daha fazlası var ise 3 adet VM oluşuyor. vSphere HA veya vSphere DRS’i aktif etmeseniz bile vCLS VM’leri oluşturulur.

vSphere Cluster Services

vCLS aslında Cluster’ın omurgası olarak tanımlanıyor. Yani vCenter Server down olduğu zaman vSphere HA ve vSphere DRS‘in işlevlerinde bir kesinti olmadığı belirtiliyor. Aslında vCLS doğrudan DRS ile birlikte çalışıyor. Yani vCenter Server down duruma geldiğinde DRS çalışmıyor ancak vCLS burada bu sorunu çözüyor ve DRS’i çalışır hale getiriyor. vSphere HA içinde vCLS önemli.

Ancak burada vSphere HA’in çalışmasına do��rudan etki etmiyor. vCenter Server down duruma geldiğinde vSphere HA yine çalışmaya devam ediyor çünkü vSphere HA aktif hale getirdiğinizde vSphere HA agent’ları ESXi host’lar üzerine yükleniyor. Bu konu ile ilgili aşağıdaki makalemi inceleyebilirsiniz. vCenter Server down olduğunda vSphere HA’in VM’leri power on etme işlemi sırasında, eğer vSphere DRS aktif durumda ise kaynak kullanımı en az olan ESXi host üzerinde VM’i power on duruma getirir. Aynı zamanda VM’ler power on olduğunda yük değişikliğine göre vSphere DRS, VM’i farklı bir host’a migrate edebilir. Tüm bu işlemleri vCenter Server down duruma geldiğinde vCLS üstleniyor ve o bu işlemlerin gerçekleşmesini sağlıyor.

Objective 2.2 – Describe HA solutions for vSphere

vCLS default olarak aktif halde geliyor ve bir VM oluşturuyor diye belirttim. Peki bu VM üzerinde herhangi bir bakım yani update/upgrade yapmanıza gerek bulunuyor mu? Bunun cevabı hayır. vCLS VM’leri ESX Agent Manager tarafından yönetiliyor. Bundan dolayı ekstra olarak bir yönetim ihtiyacı bulunmuyor. ESX Agent Manager tarafından yönetim sağlanıyor ancak gerektiği durumlarda ESX Agent Manager vCLS VM’lerini silebilir ve yeniden deploy edebilir. Bundan dolayı aslında maksimum 3 tane VM olabiliyor. VM’ler gerektiğinde ESX Agent Manager tarafından silnip deploy edildiği için bu sayının artmaması için 3 ile sınırlandırıldığı belirtiliyor. Bu VM’ler üzerinde Photon OS işletim sistemi bulunuyor. Normal VM’lerden farklı olarak vCLS VM’leri üzerinde network kartı bulunmuyor. vCLS VM’lerinin konfigurasyonunu aşağıda görebilirsiniz.

Memory: 128MB

Memory Reservation: 100MB

Swap Size: 256MB

vCPU: 1

vCPU Reservation: 100Mhz

Disk: 2GB

Ethernet Adapter: Bulunmuyor.

Guest VMDK Size: 245MB

Storage Space: 480MB

Buraya kadar her şey normal ancak Network kartı bulunmadan bu VM’ler nasıl çalışıyor ve nasıl iletişim kuruyor diye sorabilirsiniz. vCLS VM’lerin ESXi host ile iletişim kurması için VMCI/vSOCKET arayüzünü kullanır. Bundan dolayı ekstra olarak network trafiğini kullanmaz. Network kartını kullanmaması avantajlı bir şey çünkü migrate ve sonrasında oluşabilecek network sorunlarının önüne geçmiş oluyor. vCLS VM’leri otomatik olarak bir VMFS datastore’unda oluşur ancak ilk kurulum esnasında bir shared datastore vermemiş olabilirsiniz. Böyle bir durumda vCLS VM’leri local disklere oluşacaktır. Ortama shared disk ekledikten sonra Storage vMotion ile Shared disk‘e taşımanız önerilmektedir. Eğer VSAN ortamı kullanıyorsanız, VSAN’da da kesinlikle ve kesinlike shared VSAN disk’ine migrate edilmesi öneriliyor.

vCLS VM’leri oldukça düşük CPU, Memory, Disk konfigurasyonu ile çalışmaktadır. Herhangi bir bakım gereksinimi olmadığı için varlığından çok haberdar olmayabilirsiniz 🙂 Host and Cluster tab’ında gözükmediğini sadece VM and Templates bölümünde gözüktüğünü ayrıca belirtmek isterim.

Peki vCLS’i devre dışı bırakabilir misiniz? Bunun cevabı evet fakat VMware tarafından önerilen bir işlem değildir bu. Çünkü çalışmasının hiç bir olumsuz etkisi bulunmadığı gibi kaynak kullanımı oldukça azdır. Ayrıca vCenter Server’in down olması durumunda Cluster’ın normal bir şekilde işleyişe devam etmesi önemli bir durumdur. Devre dışı bırakma ile ilgili ayrıca bir makale yazacağım.

vCLS’in düzgün bir şekilde çalıştığını anlamak için aşağıdaki ekranı kullanabilirsiniz.

vSphere Cluster Services’in düzgün şekilde çalışıp çalışmadığını anlamak için sağlık durumunu yani Cluster Services health’i kontrol etmeniz gerekir.

Healthy: Eğer Cluster’da çalışan en az 1 tane vCLS VM var ise, vSphere Cluster Services’in durumu Healthy olarak işaretlenir.

Degraded: Eğer Cluster’da bozulmuş durumda olan en az 1 tane vCLS VM var ve bu VM’e 180 saniyeden kısa sürede erişim bulunmaz ise, vSphere Cluster Services’in durumu Degraded olarak işaretlenir. vCLS VM’in yeniden oluşturulması aşamasında Degraded uyarılarının görülmesi normaldir.

Unhealthy: Eğer Cluster’da bozulmuş durumda olan en az 1 tane vCLS VM var ve bu VM’e 180 saniyeden uzun sürede erişim bulunmaz ise, vSphere Cluster Services’in durumu Unhealthy olarak işaretlenir.

Aşağıdaki şartların oluşması durumunda vCLS’in sağlık durumu değişebilir. Yani aşağıdaki işlemleri yaparsanız Degraded veya Unhealthy durumları ile karşılaşabilirsiniz.

vCLS sanal makinelerinin güç durumunu değiştirme. Power off veya Power on işlemleri

vCLS sanal makinelerinin CPU, Memory, Disk boyutu gibi kaynakların yeniden yapılandırılması

VM Encryption

vCLS sunucularını vMotion ile migrate etmek

BIOS’u değiştirme

vCLS sanal makinelerini inventory’den kaldırma

vCLS sanal makinelerinin disklerini silme

vCLS sanal makineleri üzerinde Fault Tolerance’ı etkinleştirme

vCLS sanal makinelerini Clone alınma işlemi

PMem’i Yapılandırma

vCLS VM’i farklı bir klasöre taşıma

vCLS sanal makinelerinin ismini değiştirme

vCLS klasörlerinin ismini değiştirme

vCLS sanal makinelerinde DRS kurallarını değiştirme

vCLS sanal makinelerinde HA adminission control policy’i etkinleştirme

vCLS sanal makinelerinde HA overrides ‘i etkinleştirme

vCLS sanal makinelerini bir resource pool’a taşıma

vCLS sanal makinelerini bir snapshot’dan revert etmek

Yukarıdaki şartların oluşması durumunda vCLS’in sağlık durumunda Degraded ve Unhealthy gibi uyarılar ile karşılaşabilirsiniz.

vSphere 7.0 Update 1 ile birlikte gelen bu özellik oldukça güzel ve kullanışlı. İlerleyen versiyonlar ile birlikte özellikle vCLS tarafında farklı yeniliklerin olacağını tahmin ediyorum. Artık vCenter Server herhangi bir sebepten dolayı down duruma geldiğinde vSphere ve vSphere DRS gibi cluster servislerinin çalışmasında bir aksama olmayacağı belirtiliyor. İlerleyen makalelerde vCLS VM’leri üzerinde daha detaylı incelemer yapacağım. Konu ile ilgili VMware’in makalesine buradan ulaşabilirsiniz.

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/vcenter-server-7-yenilikleri.html

vCenter Server 7 Yenilikleri

Merhaba,

vCenter Server 7 Yenilikleri ile ilgili bu yazımda sizlere vCenter Server 7 ile birlikte gelen yeni özelliklerden bahsedeceğim. vSphere 7 ile birlikte gelen yenilikleri daha önce anlatmıştım. Bu yazılarıma aşağıdaki linkten ulaşabilirsiniz.

vSphere 7 Yenilikleri

vSphere 6.7 vs vSphere 7

VSAN 7 Yenilikleri

vCenter Server 7 Yenilikleri

vSphere 7 ile birlikte vCenter Server 7 üzerinde de önemli yenilikler geldi. Ben bu yeniliklere yukarıdaki linkte kısmen belirtmiştim. Bu yazımda doğrudan vCenter Server 7 ile birlikte gelen yeniliklerden bahsedeceğim. Öncelikle vCenter Server 7 ile birlikte gelen yenilikleri kısa başlıklar halinde yazalım ve ardından bunları detaylı olarak inceleyelim.

Öncelikle şunu söylemem gerekiyor, vCenter Server 7 ile birlikte artık Windows vCenter Server bulunmuyor. Artık yanlızca ve yanlızca vCenter Server Appliance kullanacağız. vCenter Server Appliance’in yönetimini yapmanız için linux bilmenize gerek bulunmuyor. Web arayüzü üzerinden tüm işlemlerinizi gerçekleştiriyorsunuz. Photos OS Linux v3.0 işletim sistemine sahiptir. vCenter Server 7 ile birlikte artık vSphere Web Client’da bulunmuyor. Artık tüm işemlerimizi vSphere Cient üzerinden yani HTML5 Client üzerinden yapacağız.

vCenter Server’in upgrade’ini yapmak için minimum vCenter Server 6.5 veya vCenter Server 6.7 versiyonunsa hip olmanız gerekiyor. vCenter Server Appliance yanlıca bir ESXi üzerine kurulduğu için ESXi sürümünün minimum ESXi Server 6.5 olması gerekir.

vCenter Server, vCenter Server 6.5 ve 6.7’den yükseltmeleri destekler, ancak vCenter Server cihazının temiz dağıtımı yalnızca ESXi ana bilgisayar sürümü 6.5 veya daha yenisinde desteklenir. ESXi 6.0’da vCenter sunucu 7.0’ı dağıtamazsınız.

vCenter Server Profiles

Update Planner

Upgrade & Converge

Multi-homing support

VM Template Management and Versioning

vCenter Server 7 Yenilikleri

vCenter Server 7 ile birlikte vSphere Client ‘da da bazı ufak değişiklikler yapıldı. vSphere Client’a login olduktan sonra Host And Clusters bölümünde vCenter Server’i seçtiğinizde karşınıza bu vCenter Server’in versiyon bilgilerini, en son ne zaman update edildiğini hatta en son alınan file based backup’ın zamanını bile görebilirsiniz. Bu oldukça güzel bir gelişme. Tek ekrandan tüm detaylara ulaşabileceğiz.

Gelen yenilikler hakkında detaylı bilgi vermeye başlayalım.

vCenter Server Profiles:

Önemli: Bu özelliği ESXi host profile ile karıştırmayınız.

VMware vCenter Server Profiles sayesinde, vCenter Server üzerindeki yapılandırmayı export edebilmeyi ve bunu farklı bir vCenter Server’a import etmemize izin veren bir API arabirimi sağlayan bir özelliktir. Oldukça güzel ve tercih edilecek bir özellik. Bu 4 farklı REST API kullanılarak gerçekleşir. Bunlar;

List

Export

Validate

Import

vCenter Server Profiles

List API, export edilebilen yapılandırmaların bir listesini çıkartır. Eğer isterseniz JSON olarak export edebilir ve gerekirse düzenleyebilirsiniz. Validate API, hedef vCenter Sunucusu ile ilgili yapılandırmanın kontrol edilmesine izin verir. Import API, istenen yapılandırma değişikliklerini istenen vCenter Sunucusuna almak için çalıştırılır.

vCenter Server Profiles

vCenter Server’a login olduktan sonra Developer Center altında API Explorer altından appliance’ı seçmeniz durumunda API’ları görebileceksiniz ve belirtmiş olduğum işlemleri yapabileceksiniz.

Update Planner:

vCenter Server 7 ile birlikte, lifecycle management yani yaşam döngüsü yönetiminde ciddi anlamda çalışma yapmıştır. Bu sayede hem ESXi hemde vCenter Server’in lifecycle management’ini yapabileceğiz.

Update planner, vCenter Server 7’de bulunan ve klasik update manager’in resmi olarak yerini alan yeni bir özellik olan vSphere Lifecycle Manager’in bir parçasıdır. Artık bu ürünü vCenter Server’in güncellemelerini gerçekleştirmek içinde kullanacağız. vCenter Server’in yaşam döngüsünü (lifecycle management) basitleştitrmek için Update Planner, güncellemeleri, patch’leri ve upgrade’leri yönetir.

Upgrade & Converge:

vCenter Server 7 ile birlikte External Platform Services Deployment artık desteklenmediği için tüm kurulum işlemlerinde yanlızca embedded seçeneği geçerli oluyor.

Upgrade & Converge

Basit bir işlem ile upgrade ve converge operasyonları gerçekleştirilebilir. Upgrade işlemi sırasında SSO domain’i external bir Platform Services Controller içeriyor ise upgrade işlemi sırasında PSC’ler embedded’a çevrilir, dönüştürülür. Upgrade sonrasında PSC’lerin decommisioning yapılması gerekmektedir. Zaten ilerleyen süre içerisinde bunun makalesini yayınlıyor olacağım.

Multi-homing support:

Bu yeni duyduğunuz bir kavram ancak beğeneceğinizi düşünüyorum. vCenter Server Appliance üzerinde artık birden fazla nic kullanabileceğiz. Normalde vCenter Server HA haricinde birden çok NIC desteklenmediği belirtilmişti. vCenter Server 7 ile birlikte artık çoklu uplink desteklenmektedir. Ancak sınırsız şekilde uplink ekleyemiyorsunuz tabiki 🙂 Maksimum 4 adet NIC ekleyebiliyorsunuz. 4 ‘den fazla ekleyebilirsiniz ancak support edilen miktar 4’dür.

Multi-homing support

Neden peki fazla nic eklememiz gerekiyor?

Bazı kuruluşların vCenter sunucusunu birden çok NIC ile yapılandırması gerekir. Bunun nedeni, özel bir yedekleme ağına sahip olmaları veya bir DMZ’nin ortak tarafında bulunan bir ESXi host’a erişmek istedikleri gerçeğinden kaynaklanmaktadır. Ayrıca, ayrı bir ağ gerektiren bazı 3. taraf izleme sistemleri olabilir.

Ek olarak NIC 1 artık VCHA için ayrılmış, rezerve edilmiştir.

VM Template Management and Versioning:

vCenter Server 7 ile birlikte bu özelliği çok beğendiğimi söylemek istiyorum. vCenter Server 7 ile birlikte template’lere verisyonlama özelliği geldi. DevOps kavramı hayatımızda artık bulunmaya başladı ve bize değişikliklerin izlenmesi ve sürümlendirilmesi gereğini hatırlattı. Github eğer kullanıyorsanız, buradaki versiyonlama veya sürüm değişikliklerini kayıt altına alma gibi işlemleri biliyorsunuzdur. vCenter Server 7 ile birlikte artık VMware bu konsepti Content Library içerisindeki Virtual Machine Template’lerinde kullanmaya başlayacak.

VM Template Management and Versioning

Bu yeni özellik sayesinde virtual machine’lerin template’lerini güncellemek için check-in ve check-out işlemlerini yapabilirsiniz. Template’leri kontrol etmek ve yeni yapılan değişiklikleri kayıt edebilir ve böylece template’leri versiyonlayabilirsiniz.

VM Template Management and Versioning

Template’ler üzerinde en az bir değişiklik yaptıktan sonra yapılan değişiklikleri görebileceksiniz. Burada yapmış olduğunuz donanım değişiklikleri vs hepsi versiyonlanacaktır. İsterseniz bu yönetim ekranlarını değiştirebilirsiniz. Content Library içerisindeki Virtual Machine Template’lerini bu özellik sayesinde sürüm kontrollerini yapabilirsiniz. Template üzerinden yeni virtual machine’ler oluşturabilir ve böylece kullanıma başlayabilirsiniz.

Son olarak sizlere vCenter Server 7 ‘nin Configuration Maximum değerlerini paylaşmak istiyorum.

vCenter Server (Standalone)

Hosts per vCenter Server: 250

Powered-ON VMs: 30,000

Linked mode vCenter Servers:

15 per SSO domain

15,000 hosts

Powered-on VMs: 150,000

vCenter server Latency:

vCenter Server to vCenter server: 150 ms

vCenter Server to ESXi host: 150 ms

vSphere client to vCenter Server: 100 ms

vCenter Server 7 ile birlikte güzel özellikler geliyor. Elbette bazı özellikleri belki kullanmış olduğunuz yapı gereği hemen kullanamayabilirsiniz ama ilerleyen zamanlar içerisinde kullanacağınıza eminim 🙂 Benim açıkcası bu sürümde en dikkatimi çeken özellik, Update Planner ve vLCM yani LifeCycle Management özelliği. Hatta bu konuya VSAN 7 Yenilikleri isimli makalemde değinmiştim.

vCenter Server 7 Yenilikleri ile ilgili aşağıdaki videoyu izleyebilirsiniz.

Ürün release olduğunda bu yenilikleri sizlere uygulamalı olarak anlatacağım.

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/vsphere-7-yenilikleri.html

vSphere 7 Yenilikleri

Merhaba,

vSphere 7 Yenilikleri isimli bu yazımda sizlere vSphere 7 ile birlikte gelen yenilikleri kısaca bahsedeceğim. Özellikle dikkat çekici olan bazı yenilikler ile ilgili ayrıca makale hazırlayacağım. vSphere 7 ile birlikte gelen yeniliklere aşağıdaki makalelerde değinmiştim. Ancak bu makalede biraz daha detaylı inceleyeceğiz.

VSAN 7 Yenilikleri

vSphere 6.7 vs vSphere 7

vSphere 7 Yenilikleri

Son zamanlarda, organizasyonlar geçmişte en önemli faktör olan platformdan ziyade ana faaliyetleriyle yakından uyumlu ve öncelikli olan uygulamalar geliştirme ihtiyacının daha fazla farkına varmışlardır. Bu eğilimi kabul eden VMware, müşterilerine sadece geleneksel değil aynı zamanda modern uygulamaları sorunsuz bir şekilde barındırabilen ve yönetebilen bir platform sağlamak için portföy ürünlerini entegre etmeye çalışmaktadır. VSphere 7’nin ana odağı, bu teknolojilerin tümünü yönetmek için tek bir platforma entegre edilmesidir.

Eminim bu yazıyı okuyan bir çok kişi uzun yıllardır VMware altyapısı yönetiyordur ve bu konuda ciddi anlamda bilgi ve birikimleri bulunmaktadır. Uygulama geliştiriciler işyüklerinin anında oluşturulmasını ve hızlı bir şekilde çözümlenmesini istiyorlar. Kurumlar ve içindeki BT ekipleri, bu tarz sistemleri teslimatı için ciddi bir efor sarfediyor. Bu sistemleri teslim ettikten sonra bunların denetimi, patch, update işlemleri gibi işlemlerin yapılmasıda aslında bunun en zor olan bölümlerindendir.

  vSphere 7 ile birlikte BT yöneticlerinin bu yaşamış olduğu zorluklar ortadan kaldırılma hedefleniyor. Ve bunu destekleyen çok güzel özellikler getirildi.

Kubernetes’i platforma (Tanzu Kubernetes Grid Service aracılığıyla) native olarak entegre eden VMware Cloud Foundation 4 tarafından desteklenirken, yeni altyapı yapılarının eklenmesiyle geleneksel altyapı hizmetleri eskisi gibi çalışmaya devam ediyor. Yani bu ne demek oluyor vSphere 7 ile Kubernetes’i birlikte tek bir ekrandan sorunsuz bir şekilde kullanabiliyoruz 🙂 Geleneksel API’ler buna göre genişletildi ve geliştiriciler Kubernetes alanında alışkın oldukları komutların aynısını kullanmaya devam edebilirler.

Ayrıca, vSphere’in güvenlik, kimlik doğrulama ve yaşam döngüsü yönetiminde de aşağıda özetlenen iyileştirmeler vardır.

VMware vCenter Server 7.0 Profiles vSphere 7.0’da tamamen yeni bir özelliktir. Bunu lütfen ESXi Host Profiles ile karıştırmayın. vCenter Server 7 Profiles temel olarak REST API’leri (yönetim, ağ, kimlik doğrulama ve kullanıcı yapılandırması) aracılığıyla vCenter Server yapılandırmasını içe ve dışa aktarmamıza izin verir.

Dışa aktarılan yapılandırma (bir JSON dosyasıdır) diğer vCenter sunucularına aktarılabilir. Dağıtmak için 20-30 vCenter sunucunuz olduğunu düşünün. Tüm vCenter sunucularında yapılandırmayı sürdürmek için bu profili kullanabilirsiniz. Profiller vCenter sunucuları arasında sürüm kontrolünü koruyabilir. 100 vCenter sunucu sınırı vardır.

vCenter Server 7.0 profilleri ile geçerli bir vCenter sunucu profilini içe aktararak bilinen bir son yapılandırmaya kolayca dönebilirsiniz, böylece bir DR rolü de oynayabilir.

External Platform Services desteğinin kaldırıldığını daha önce blog üzerinden duyurmuştum ve Convergence tool sayesinde bu sürecin nasıl yapılacağını anlatmıştım. vSphere 7 ile birlikte bu konuda bir değişiklik yapılmış. Artık kurulum esnasında external seçeneği gelmiyor. Buna ek olarak vSphere 7 ile birlikte Convergence tool artık bulunmuyor yani ISO’da bulunmuyor. vSphere 7 ile birlikte external ‘dan embedded a migration işlemi oldukça basitleşiyor. vSphere 7 ile birlikte gelen bir diğer yenilik ise vCenter Server Update Planner. VMware, vSphere 7 ile birlikte update/upgrade işlemlerini çok basitleştirmek istediğini açıkca belli etmiş 🙂

vCenter Server Update Planner sayesinde update’in planlanması ve yürütülmesini kolay bir şekilde yapabiliriz. Yeni bir sürüme geçmek istediğinizde, çalışabilirlik sorunlarını görmenizi sağlayabilir veya isterseniz what if senaryolarını çalıştırabilirsiniz. Böylece upgrade yapmadan önce kendinizi güvende hissetmiş olursunuz 🙂

vSphere ESXi üzerinde bir güncelleme yapmak istediğinizde, kullanmış olduğunuz sunucuya özel driver, versiyon ve firmware updatelerini yapmanız gerekir. Bu oldukça önemlidir, eğer bunlardan birini yapmazsanız çeşitli sorunlar ile karşılaşmanız olasıdır. LifeCycle Manager sayesinde HPE ve DELL sunucularınızın update/upgrade işlemlerini sorunsuz bir şekilde gerçekleştirebilirsiniz.

vSphere 7 ‘de beni en çok heyecanlandıran özelliklerin birtaneside vSphere DRS ‘de yapılan iyileştirmelerdi. vSphere 7 ile birlikte vSphere DRS’de önemli değişilikler mevcuttur. Daha önce DRS her 5 dakikada bir çalışırken vSphere 7 ile birlikte gelen DRS’da her 1 dakikada bir çalışmaktadır. Ayrıca DRS çalışırken, VM DRS skor kullanılıyor. Peki bu ne demek hemen bundan bahsedeyim.

VM DRS Score nedir?

Bu virtual machine’in çalışma verimliliği. % 0’a yakın değerler ciddi kaynak sorunu olduğunu gösterirken % 100’e yakın değerler hafif veya hiç kaynak sıkıntısının olmadığını gösterir. DRS, cluster’da her virtual machine’in çalışma verimliliğini en üst düzeye çıkarırken tüm virtual machine’lere kaynak tahsisinde eşitliği sağlamaya çalışacaktır.

Cluster DRS Score nedir?

Cluster’da bulunan virtual machine’lerin ortalama DRS Score’udur.

VM DRS skoru % 0-20,% 20-40 gibi değerler ile çalışır ve DRS, cluster’daki ESXi Host üzerindeki virtual machine için bu score’u hesaplar.

Daha düşük score, virtual machine’in iyi çalışmadığı anlamına gelmez, ancak verimliliği ile ilgili bazı sorunlarının olduğunu gösterebilir. Virtual machine DRS Score’un hesaplanması virtual machine başına veya bir cluster’daki tüm ESXi hostlar içindir.

Virtual machine için daha düşük bir score sağlayabilecek başka bir ESXi Host var ise, bu durumda DRS, bu virtual machine’in başka bir ESXi host’a migration’ini dikkate alır.

Virtual machine DRS Score hesaplanırken, CPU Ready Time, Memory Swap gibi değerler dikkate alınır.

Genel olarak, DRS vSphere 7’ye migration konusunda çok zekidir, bu yüzden bu yeni özelliklerin virtual machine’ler üzerindeki etkisini çok merak ediyorum.

vMotion işlemleri sırasında virtual machine’in memory bilgileri taşınır. Eğer bir virtual machine’in memory miktarı yüksek ise bu virtual machine’in taşınma işlemi oldukça uzun olacaktır. Bundan dolayı yüksek memory bulunan virtual machine’ler genellikle DRS üzerinde rule yazılır ve migrate edilmez. vMotion esnasında Memory bitmap dosyası oldukça önemlidir. Büyük size’a sahip virtual machine’lerin memory bitmap dosyalarıda oldukça büyüktür. Örneğin 1GB memory bulunan bir virtual machine’in default memory bitmap’i 32GB’dir. Elbette bu size’a sahip bir virtual machine’in vMotion işlemi hızlı ve basit olacaktır. Ancak 24TB memory bulunan bir virtual machine’in memory bitmap dosyası 768MB büyüklüğündedir. Bu virtual machine vMotion ile farklı bir host’a aktarılması durumunda belirtmiş olduğun 768MB büyüklüğündeki dosyasının aktarımı virtual machine üzerinde anlık donmalara veya hang gibi işlemlere yol açabilir. 768 MB boyutundaki bir memory bitmap’in aktarılması 2 saniye sürecektir ancak bu virtual machine’in olumsuz etkilenmesine sebep olabilecektir. vSphere 7 ile birlikte memory bitmap dosyaları sıkıştırılarak geliştirilmiştir. Memory bitmap’i 24TB belleğe (768MB bellek bitmap boyutu) sahip bir virtual machine’de sıkıştırıldığı için artık aktarılması 2 saniye sürmez, yalnızca 175 mikrosaniye sürer.

vMotion ile birlikte gelen yenilikleri ayrıca yazacağım. Orada daha detaylı bilgiler vereceğim.

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-raid-6-erasure-coding.html

VSAN - RAID 6 Erasure Coding

Merhaba,

VSAN – RAID 6 Erasure Coding ile iligli spesifik olarak bir makale yazmamıştım. Bu yazımda VSAN – RAID 6 Erasure Coding ile ilgili çeşitli bilgiler vereceğim.

Daha önce VSAN RAID5/6 Erasure Coding ile ilgili bir makale yazmıştım. Bu yazıma aşağıdaki linkten ulaşabilirsiniz.

VSAN – Raid 5/6 Erasure Coding

VSAN RAID6 Kullanımı

FTT=2 kullanılmasını istenilen VSAN cluster’larının düzgün bir şekilde tasarlanması gerekir. Neden düzgün bir şekilde tasarlanması gerekir diye söylüyorum? Çünkü burada maaliyet kalemleri işin içerisinde giriyor. Bundan dolayı yedeklilik arttıkça aslında maaliyette artmış olur. Bununda sebebi depolama maliyetinden kaynaklanır. vSAN RAID 6 Erasure Coding kullanarak depolama maliyeti bir miktar telafi edilebilir. Ancak yukarıda da belirttiğim gibi FTT=2 tasarlanırken dikkat etmeniz gereken önemli noktalar bulunmaktadır.

VSAN – RAID 6 Erasure Coding Nedir?

RAID 6 kullanmanız durumunda 4 data bit ve 2 parity bit kullanılır. VMware vSAN’da verileri 4 data ve 2 parite bileşenine bölmek için erasure coding’i kullanır. Bir önceki makalemde de bilgi vermiştim ancak, bazı verilerde eksiklik olsa bile orjinal verilerinizi kurtarmanıza olanak sağlar. Tabi erasure coding’in perfromansa önemli düzeyde etkisi bulunmaktadır. VMware ‘de RAID 6 kullanabilmek için all flash kullanmanız gerekmektedir. All Flash ile Hybrid arasındaki farklar için aşağıdaki makalemi inceleyebilirsiniz.

VSAN – All Flash ve Hybrid

Erasure Coding kullanıldığı için önemli miktarda kapasite iyileştirmesi sağlanır. Örneğin FTT=2 politikası için RAID 1 kullanılırken, storage çarpanı 3 ‘dür. Yani bu ne demek oluyor? 100 GB‘lık bir virtual machine için 300 GB alan tüketilecektir. Peki RAID 6 kullanılırken bu durum nasıl oluyor ondan bahsedeyim. RAID 6 kullanıyorsanız, storage çarpanı 1.5 ‘dir. Yani 100GB‘lık bir virtual machine için yanlızca 150GB‘lık bir alan tüketecektir.

vSAN RAID 6 (Erasure Coding) Gereksinimleri

RAID 6 Erasure Coding politikalarından yararlanmak istiyorsanız, aşağıdaki gereksinimlerin karşılanması gerekir:

vSAN Advanced License

VSAN All Flash kullanılmalıdır.

Cluster’da en az 6 host bulunmalıdır.

RAID 5/6 kullanılabilmesi için disk format sürümü 3 veya üstü olması gerekir.

Daha detaylı bilgi için aşağıdaki linki inceleyebilirsiniz.

https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.virtualsan.doc/GUID-6D818555-8DE8-4F06-9498-66903FB9C775.html

VSAN yapılandırma özelliklerine girmeden önce, ESXi host’ların fiziksel olarak ayırmak en iyi yöntemdir. Genellikle cluster içerisinde bulunan sunucular farklı yerlerde yani farklı kabinlerde olması tercih edilir. Burada en önemli gereksinim, cluster’da bulunan ESXi host’lar arasında 1ms RTT olması gerekir. RAID 6 erasure coding politikalarını kullanmanın minimum 6 ESXi host gereksinimi olduğu göz önüne alındığında, bir cluster’ı 6 veya daha fazla rack’e bölmek ideal olacaktır.

Aslında bu makale içerisinde fault domain hakkında da bilgi verecektim ancak Fault Domain ile ilgili daha önce kapsamlı bir yazı yazmıştım. Buna aşağıdaki linkten ulaşabilirsiniz.

VSAN – Fault Domain

VSAN – RAID 6 Erasure Coding

VSAN RAID 6 kullanmak istiyorsanız Storage Policy’den yeni bir policy oluşturabilir veya var olan storage policy’i değiştirebilirsiniz.

Umarım faydalı olmuştur.

Iyi ç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/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.