tayfundeger

[tayfundeger]

New Post has been published on VMware Virtualization Blog

New Post has been published on https://www.tayfundeger.com/runecast-ile-guvenlik-analizi-nasil-yapilir.html

Runecast ile Güvenlik Analizi Nasıl Yapılır?

Merhaba,

Runecast ile Güvenlik Analizi Nasıl Yapılır? isimli bu yazımda sizlere VMware ortamlarında Runecast’ı kullanarak güvenlik analizi nasıl yapılacağı konusunda detaylı bilgi vereceğim. Daha önce yazmış olduğum Runecast ile ilgili makalelere aşağıdaki linkten ulaşabilirsiniz.

https://www.tayfundeger.com/?s=Runecast

Günümüzde IT altyapılarında güvenlik oldukça önemlidir. Artan güvenlik açıkları ve bunun sonucunda altyapılara sızma işlemlerinin yapılması oldukça yaygındır. Donanım üreticileri ve yazılım üreticileri, yapmış oldukları güvenlik güncelleştirmeleri ile bu sorunları düzeltebilmektedir. Örneğin geçtiğimiz yıl ortaya çıkan L1 Terminal Fault güvenlik açığı hem fiziksel donanım katmanını hemde sanallaştırma katmanında önemli patch’ler yayınlandı. VMware katmanında ESXi ve vCenter Server tarafında güvenlik açıkları yayınlanırken, donanım üreticileride yeni firmware çıkararak bu güvenlik açığını düzeltmek durumunda kaldı.

Meltdown, Rogue System Register Read ve Lazy FP State Restore gibi etkilenen Intel mikroişlemcilerinin izinsiz veri erişimi yapması durumunda L1 Terminal Fault güvenlik açığı oluşabilir. ESXi ile birlikte biz aslında bir sanallaştırma yapıyoruz. Fiziksel sunucu üzerindeki tüm donanımı sanallaştırıyoruz diyebiliriz. ESXi kurulumundan sonra üzerinde birden fazla virtual machine çalıştırarak fiziksel sunucunun CPU ‘sunu daha efektif bir şekilde kullanıyoruz. Tüm virtual machine’ler CPU core’larını ortak bir şekilde kullanabiliyor. Bu açık sayesinde CPU üzerinde bulunan L1 cache‘inde yer alan bilgi okunabilmektedir. Public cloud ortamında altyapınız var ve bu açıktan dolayı tüm virtual machine’leriniz üzerinde yer alan bilgiler izinsiz birşekilde okunabilir.

Elbette ben burada sadece birtane güvenlik açığını örnek verdim ancak yıl içerisinde birden fazla güvenlik açığı ile karşılaşabiliyoruz. Eğer bu güvenlik açıklarında doğru zamanda müdahale etmez isek altyapımızı riske atmış oluruz. Çünkü güvenlik açıklarına zamanında müdahale edilmediğinde, altyapınız sürekli olarak risk altında olur. Her an altyapının hack edilmesi riski ile karşı karşıya kalırız.

Runecast ile Güvenlik Analizi Nasıl Yapılır?

Runecast kullanılan altyapılarda güvenlik açıklarını hem kolayca takip edebilir hemde altyapınıza uygunluğu konusunda detaylı bilgiye sahip olabilirsiniz. Eğer büyük bir altyapınız var ise zaten güvenlik açıklarını takip etme konusunda zorluklar çekebilirsiniz. Runecast sizlere güvenlik açıkları konusunda oldukça fayda sağlar. Runecast’a login olduktan sonra, Vulnerabilities bölümüne login olduğunuzda güvenlik açıklarını görebilirsiniz. Runecast birden fazla platformu desteklediği için isterseniz kullanmış olduğunuz platforma göre filtreleyebilirsiniz. Ben aşağıdaki örnekte vSphere’i sadece filtreledim. Yine isterseniz önem derecesine göre güvenlik açıklarını ve bültenlerini filtreleyebilirsiniz.

Runecast ile Güvenlik Analizi Nasıl Yapılır?

Vulnerabilities bölümüne girdiğinzide altyapınızdaki güvenlik açıkları gösterilir. Bu güvenlik açıkları anlık ve tam zamanlı olarak takip edildiği için yeni bir güvenlik açığının olması ve bundan dolayı altyapınızın etkilenip etkilenmediğini hemen görebilirsiniz. Ayrıca altyapınızın güvenlik açıklarından etkilenme durumunuda Dashboard bölümünden görebilirsiniz. Karşılaştığınız güvenlik açıklarını seçip Details bölümünden güvenlik açığının detaylarını Findings bölümünden ise etkilenen sistemleri görebilirsiniz.

Tüm bu işlemleri basit bir şekilde tek bir ekrandan görebilirsiniz. Runecast kullanmıyorsanız bu güvenlik açıklarını görebilmek için tek tek inceleme yapmanız gerekmektedir. Bu durumun size zaman kaybı çok fazladır. Her bir çıkan güvenlik açığının altyapınızda olup olmadığını denetlemeniz oldukça zaman kaybettirir. Runecast üzerinde tespit ettiğiniz güvenlik açıklarını isterseniz export olarak alabilirsiniz. Yani burada yer alan güvenlik açıklarını eğer farklı bir yerde sunmak istiyorsanız CSV ve PDF olarak export alabilirsiniz.

Güvenlik açıklarını kapatmak için çoğu zaman bir güvenlik güncellemesi yüklüyoruz. Yüklemiş olduğunuz güvenlik güncelleştirmesi bazı durumlarda altyapınız ile uyumlu olmayabilir. Böyle durumlar yine Runecast’den faydalanabilirsiniz. Runecast’a login olduktan sonra HW Compatibility bölümünden altyapınızdaki donanım uyumluluklarını görebilir ve bunları simule edebilirsiniz. Altyapınızda bulunan ESXi host’ların hepsini, update veya upgrade etmek istediğiniz versiyona göre test edebilirsiniz.

Örneğin ESXi 6.7 U1 kullanıyorsunuz ancak tespit ettiğiniz güvenlik açığı ESXi 6.7 U3 ile kapanıyor. Altyapınızı ESXi 6.7 U3 ile uyumlu olup olmadığını ve bu update’e geçtikten sonra hangi donanım firmware’lerinin güncellenmesi gerektiğini detaylı olarak raporlayabilir ve bunun neticesinde aksiyonlar alabilirsiniz.

Runecast’in özellikle VMware altyapılarında önemli rollerinin olduğunu daha önceki makalelerimde de vurgulamıştım. Eğer büyük bir VMware ortamınız var ise ve altyapınızı tam zamanlı izlemek istiyorsanız Runecast tam size göre bir araç.

Runecast Vmware Analyzer – Türkiye Distribütör firması “OTD Bilişim” satış ekibi otd.salesgrp@onlineteknikdestek.com  ile iletişime geçebilirsiniz.

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/runecast-ile-denerinlemesine-analiz.html

Runecast ile Denerinlemesine Analiz

Merhaba,

Runecast ile Denerinlemesine Analiz isimli bu yazımda sizlere Runecast ürünlerinin desteklediği platformlar ile ilgili detaylı bilgiler aktaracağım.

Daha önce Runecast ile ilgili yazmış olduğum makalelere aşağıdaki linkten ulaşabilirsiniz.

Runecast Kubernetes Ortamınızı Nasıl Analiz Eder?

Runecast ile VMware Upgrade Planları Nasıl Yapılır?

Runecast 5.1 ile Gelen Yeni Özellikler

Runecast ile Denerinlemesine Analiz

Runecast sayesinde VMware altyapılarınızı proaktif olarak izleyebilirsiniz. Eğer büyük bir altyapı yönetiyorsanız bu sizin için oldukça önemlidir. Çünkü Runecast kullanmıyorsanız altyapınızı manuel olarak takip etmek durumunda kalacak ve tüm bunlara ek olarak size ciddi bir zaman kaybı olacaktır. Runecast sadece VMware altyapılarında fayda sağlamıyor. Son zamanlarda container mimarilerinin önemli yapı taşlarından olan Kubernetes ortamlarınıda proaktif izliyor ve sizlere konfigurasyon hataları ile ilgili çözümlar sunuyor. Eğer altyapınızda AWS ve Azure kullanıyorsanızda size fayda sağlıyor.

Diyelim ki çalıştığınız firmada AWS, Azure, Kubernetes ve VMware kullanıldığını düşünelim. Bu altyapıların hepsinin güvenlik açıklarını kendiniz takip etmeniz oldukça zor. Elbette takip edebilirsiniz ancak gözden kaçırdığınız şeylerde olacaktır mutlaka.

Runecast Analyzer, yukarıda belirtmiş olduğum tüm altyapıları tarar ve Best Practices’e aykırı bir durum var ise bunu size bildirir, tüm bunlara ek olarak Security Hardening kontrollerini sağlar. AWS, Azure, Kubernetes ve VMware için güvenlik açığı yönetimizi ve güvenlik standartlarına uygunluk denetiminizi Runecast sayesinde otomatikleştirebilirsiniz. Bu oldukça önemlidir. Son zamanlarda güvenlik açıklarının yeterince kontrol edilmemesinden kaynaklı bir çok firmadan dışarı veri sızdırıldı. IT yöneticileri genellikle tek bir iş ile uğraşmadıkları için güvenlik açıklarını gözden kaçırmaları durumunda sonuçları felaket olabiliyor.

Runecast ile Denerinlemesine Analiz

Eğer AWS kullanıyorsanız, Runecast ile AWS ortamlarınızıda koruma altına alabilirsiniz. Runecast Analyzer, tüm olası yanlış yapılandırmaları ve en iyi uygulama ihlallerini otomatik olarak tespit ederek, Ulusal Standartlar ve Teknoloji Enstitüsü (NIST) Özel Yayını 800-53 uyumluluk kontrollerini yürütürken yaşanan sıkıntıları ortadan kaldırır. Runecast, BT ekiplerinin ve kuruluşlarının siber güvenlik duruşlarını otomatikleştirip iyileştirmesini sağlamak için NIST siber güvenlik çerçevesinin beş temel işlevini (Tanımlama, Koruma, Algılama, Yanıtlama ve Kurtarma) bir araya getirir. Ayrıca, PCI DSS, GDPR, ISO 27001 güvenlik denetimlerinide sağlar.

AWS için NIST uyumluluk kontrolleri, Runecast Analyzer’ın AWS desteğini şu şekilde genişletir: AWS Health, CloudWatch, Redshift, RDS, CloudTrail, CloudFront, AWS Config, EC2, IAM, S3, VPC. AWS için NIST uyumluluğuna karşı otomatik denetimler sayesinde ekibiniz ve şirketiniz, düzenli olarak güncellenen karmaşık güvenlik uyumluluğu standartları için “denetime hazır” olabilir ve kalabilir.

Runecast Analyzer, Microsoft Azure ortamınızın Azure Best Practices’e ve çeşitli standartlara  karşı sürekli proaktif olarak izler ve bunu otomatik hale getirir. Azure altyapınızda bir sorun olduğunda ise sorunun nerede olduğunu size hemen gösterir. Kritik sorunların bir listesini ve bunları gidermek için gereken adımları basitçe görebilirsiniz.

Aşağıdaki Azure Servisleri support edilmektedir.

Azure Active Directory

Azure App Services

AKS (Azure Kubernetes Service)

Disks

Key Vault

Subscriptions

MySQL Server

Network Security Groups

PostgreSQL Server

SQL Server

Storage Accounts

Virtual Machines

Azure altyapılarında konfigurasyon farklılıklarını incelemek için Configuration Vault özelliğini kullanabilirsiniz. Bu özellik sayesinde Azure üzerinde değişen konfigurasyon farklılıklarını görebilir ve bunları raporlayabilirsiniz.

Runecast kullanıyorsanız NSX-T ve NSX-V ortamlarını proaktif olarak izleyebilirsiniz. Altyapınızda kurulu olan NSX-T veya NSX-V ürünlerinin konfigurasyonlarını VMware Best Practices dökümanlarına göre karşılaştırır gerekli korelasyonu yaptıktan sonra altyapınızda bulunan konfigurasyon hatalarını çıkartır. Bu hataları Best Practices dökümanları ile karşılaştırarak çözüm konusunda size yardımcı olur. Ayrıca NSX üzerinde bulunan güvenlik açıkları, CVE belirtilerek size raporlanır. Böylece NSX üzerinde oluşan güvenlik açıkları ve konfigurasyon hatalarını kısa süre içerisinde çözebilir ve network altyapınızı daha güvenli bir hale getirebilirsiniz.

Runecast Vmware Analyzer – Türkiye Distribütör firması “OTD Bilişim” satış ekibi otd.salesgrp@onlineteknikdestek.com  ile iletişime geçebilirsiniz.

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/runecast-ile-derinlemesine-analiz.html

Runecast ile Derinlemesine Analiz

Merhaba,

Runecast ile Derinlemesine Analiz isimli bu yazımda sizlere Runecast ürünlerinin desteklediği platformlar ile ilgili detaylı bilgiler aktaracağım.

Daha önce Runecast ile ilgili yazmış olduğum makalelere aşağıdaki linkten ulaşabilirsiniz.

Runecast Kubernetes Ortamınızı Nasıl Analiz Eder?

Runecast ile VMware Upgrade Planları Nasıl Yapılır?

Runecast 5.1 ile Gelen Yeni Özellikler

Runecast ile Derinlemesine Analiz

Runecast sayesinde VMware altyapılarınızı proaktif olarak izleyebilirsiniz. Eğer büyük bir altyapı yönetiyorsanız bu sizin için oldukça önemlidir. Çünkü Runecast kullanmıyorsanız altyapınızı manuel olarak takip etmek durumunda kalacak ve tüm bunlara ek olarak size ciddi bir zaman kaybı olacaktır. Runecast sadece VMware altyapılarında fayda sağlamıyor. Son zamanlarda container mimarilerinin önemli yapı taşlarından olan Kubernetes ortamlarınıda proaktif izliyor ve sizlere konfigurasyon hataları ile ilgili çözümlar sunuyor. Eğer altyapınızda AWS ve Azure kullanıyorsanızda size fayda sağlıyor.

Diyelim ki çalıştığınız firmada AWS, Azure, Kubernetes ve VMware kullanıldığını düşünelim. Bu altyapıların hepsinin güvenlik açıklarını kendiniz takip etmeniz oldukça zor. Elbette takip edebilirsiniz ancak gözden kaçırdığınız şeylerde olacaktır mutlaka.

Runecast Analyzer, yukarıda belirtmiş olduğum tüm altyapıları tarar ve Best Practices’e aykırı bir durum var ise bunu size bildirir, tüm bunlara ek olarak Security Hardening kontrollerini sağlar. AWS, Azure, Kubernetes ve VMware için güvenlik açığı yönetimizi ve güvenlik standartlarına uygunluk denetiminizi Runecast sayesinde otomatikleştirebilirsiniz. Bu oldukça önemlidir. Son zamanlarda güvenlik açıklarının yeterince kontrol edilmemesinden kaynaklı bir çok firmadan dışarı veri sızdırıldı. IT yöneticileri genellikle tek bir iş ile uğraşmadıkları için güvenlik açıklarını gözden kaçırmaları durumunda sonuçları felaket olabiliyor.

Runecast ile Derinlemesine Analiz

Eğer AWS kullanıyorsanız, Runecast ile AWS ortamlarınızıda koruma altına alabilirsiniz. Runecast Analyzer, tüm olası yanlış yapılandırmaları ve en iyi uygulama ihlallerini otomatik olarak tespit ederek, Ulusal Standartlar ve Teknoloji Enstitüsü (NIST) Özel Yayını 800-53 uyumluluk kontrollerini yürütürken yaşanan sıkıntıları ortadan kaldırır. Runecast, BT ekiplerinin ve kuruluşlarının siber güvenlik duruşlarını otomatikleştirip iyileştirmesini sağlamak için NIST siber güvenlik çerçevesinin beş temel işlevini (Tanımlama, Koruma, Algılama, Yanıtlama ve Kurtarma) bir araya getirir. Ayrıca, PCI DSS, GDPR, ISO 27001 güvenlik denetimlerinide sağlar.

AWS için NIST uyumluluk kontrolleri, Runecast Analyzer’ın AWS desteğini şu şekilde genişletir: AWS Health, CloudWatch, Redshift, RDS, CloudTrail, CloudFront, AWS Config, EC2, IAM, S3, VPC. AWS için NIST uyumluluğuna karşı otomatik denetimler sayesinde ekibiniz ve şirketiniz, düzenli olarak güncellenen karmaşık güvenlik uyumluluğu standartları için “denetime hazır” olabilir ve kalabilir.

Runecast Analyzer, Microsoft Azure ortamınızın Azure Best Practices’e ve çeşitli standartlara  karşı sürekli proaktif olarak izler ve bunu otomatik hale getirir. Azure altyapınızda bir sorun olduğunda ise sorunun nerede olduğunu size hemen gösterir. Kritik sorunların bir listesini ve bunları gidermek için gereken adımları basitçe görebilirsiniz.

Aşağıdaki Azure Servisleri support edilmektedir.

Azure Active Directory

Azure App Services

AKS (Azure Kubernetes Service)

Disks

Key Vault

Subscriptions

MySQL Server

Network Security Groups

PostgreSQL Server

SQL Server

Storage Accounts

Virtual Machines

Azure altyapılarında konfigurasyon farklılıklarını incelemek için Configuration Vault özelliğini kullanabilirsiniz. Bu özellik sayesinde Azure üzerinde değişen konfigurasyon farklılıklarını görebilir ve bunları raporlayabilirsiniz.

Runecast kullanıyorsanız NSX-T ve NSX-V ortamlarını proaktif olarak izleyebilirsiniz. Altyapınızda kurulu olan NSX-T veya NSX-V ürünlerinin konfigurasyonlarını VMware Best Practices dökümanlarına göre karşılaştırır gerekli korelasyonu yaptıktan sonra altyapınızda bulunan konfigurasyon hatalarını çıkartır. Bu hataları Best Practices dökümanları ile karşılaştırarak çözüm konusunda size yardımcı olur. Ayrıca NSX üzerinde bulunan güvenlik açıkları, CVE belirtilerek size raporlanır. Böylece NSX üzerinde oluşan güvenlik açıkları ve konfigurasyon hatalarını kısa süre içerisinde çözebilir ve network altyapınızı daha güvenli bir hale getirebilirsiniz.

Runecast Vmware Analyzer – Türkiye Distribütör firması “OTD Bilişim” satış ekibi otd.salesgrp@onlineteknikdestek.com  ile iletişime geçebilirsiniz.

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/runecast-ile-log-analizi-nasil-yapilir.html

Runecast ile Log Analizi Nasıl Yapılır?

Merhaba,

Runecast ile Log Analizi Nasıl Yapılır? isimli bu yazımda sizlere Runecast ile birlikte VMware altyapılarında logların nasıl inceleneceği ve Runecast’ın bize sağlamış olduğu faydalardan bahsedeceğiz.

Daha önce Runecast ile ilgili yazmış olduğum makalelere aşağıdaki linkten ulaşabilirsiniz.

Runecast Kubernetes Ortamınızı Nasıl Analiz Eder?

Runecast ile VMware Upgrade Planları Nasıl Yapılır?

Runecast 5.1 ile Gelen Yeni Özellikler

Runecast ile Log Analizi Nasıl Yapılır?

Runecast sayesinde VMware ortamlarını daha verimli bir şekilde izlediğimizi ve bunun bize ciddi zaman kazandırdığı konusunda zaten daha önceki makalelerimde bilgi vermiştim. Bu yazımda ise, Runecast ile log analizinin nasıl yapılacağı ve bunun bize sağladığı faydalardan bahsedeceğim. Runecast kullanıyorsanız 2 farklı yöntem ile log analizi yapabilirsiniz. Log KBs Discovered ve Log Inspector seçenekleri ile VMware ortamlarınızı log analizini proaktif olarak yapabilirsiniz. Zaten Runecast’ın en büyük özelliklerinden birtaneside altyapınızı proaktif olarak izleyebilmesi ve belirli otomasyonlar sayesinde zaman tasarrufu yapmasıdır.

Log KBs Discovered:

Bu özellik sayesinde, tam zamanlı ve anlık olarak izlenir. Log dosyalarınız içerisinde error ve warning başlıklı loglar VMware KB’leri ile karşılaştırılır. Bunun neticisinde altyapınızda bulunan hata log’unun çözümü ile ilgili log karşınıza getirilir. Yani hemen şöyle bir örnek verelim. Altyapınızda storage ile ilgili bir iletişim sorunu var. Bunun neticisinde vmkernel logları içerisinde APD ve PDL logları görüyorsunuz. Bu tarz durumlarda ortamınıza çok acil bir şekilde müdahale edilmesi gerekir. Aksi halde virtual machine’ler dahil tüm sanallaştırma altyapınızı kaybedebilir veya erişilmez duruma getirebilirsiniz. Sorunlar ilk olarak küçük bir şekilde başlar ve farkına varmazsınız.

Bu sorunlar ilerledikçe artık altyapınız çalışmaz duruma gelmeye başlar. İşte tüm bu süreçleri yaşamak istemiyorsanız altyapınızı proaktif bir şekilde izlemeniz gerekiyor. Eğer işiniz sadece VMware değil ve günlük hayatta IT tarafında farklı farklı konular ve işler ile uğraşıyorsanız altyapınızı 3party bir tool ile izlemeniz gerekiyor. Çünkü bu sorunlar başınıza geldiğinde eğer incelemeye başlarsanız ciddi anlamda vakit kaybedersiniz. Vakit kaybının olması ise altyapınızda daha uzun kesintiler yaşamanıza sebep olacaktır.

Log KBs Discovered özelliği log dosyaları ile KB makaleleri ‘nin korelasyonuna dayalı bir çözümdür. Log’ların içerikleri VMware KB makalelerinde sürekli olarak aranır ve karşınıza en uygun sonuçlar gelir. Yukarıda bahsettiğim log dosyaları içerisinde tek tek veri aramanızı ve bunun neticesinde oluşacak zaman kaybını Runecast ortadan kaldırır.

Log Inspector:

Bu özellik sayesinde VMware KB‘lerde belgelenen sorunların yanı sıra Runecast, logların bir soruna işaret edebilecek yaygın hata mesajlarını filtreler ve etiketler. Etiketli loglar veya log içerikleri diyelim, yönetici tarafından incelenebilecek bir geçmiş grafikte gösterilir. Log tablosunun altında daha küçük bir navigasyon tablosu bulunur. Navigasyon tablosu, görüntülenen logların zaman aralığını değiştirmek için kullanılabilir.

Log Inspector üzeirnde sizin belirlemiş olduğunuz kelime öbeklerini aratabilir ve bunları tarih aralıkları halinde sıralayabilirsiniz. Ben genellikle Error ve warning kelimelerini aratarak burada karşıma gelen sonuçları inceliyorum. Ancak tabiki siz yaşamış olduğunuz sorunlara bağlı olarak farklı kelime öbeklerinide aratabilirsiniz.

Log KBs Discovered özelliğini kullanmak için Runecast’a login olduktan sonra sol bölümde yer alan Log KBs Discovered butonuna giriş yapıyoruz.

Runecast ile Log Analizi Nasıl Yapılır?

Runecast ile Log Analizi Nasıl Yapılır? Log KBs Discovered bölümünü açtığımızda karşımıza direk altyapımızda oluşan sorunlar ve bunların çözümleri ile ilgili olan VMware KB’lerini görüyoruz. Burada elbette önem derecesine göre sorunlar sınıflandırılmış durumdadır. Yukarıdaki örnekte Emulex network kartının down olduğu görülüyor. Bunun çözümü ile ilgili olan KB’yi Reference bölümünden görebilirsiniz.

https://kb.vmware.com/s/article/50106632

Aslında bu örnekte yer alan sorununda çözümü driver ve firmware ile ilgili. Eğer Runecast kullanıyorsanız HW Compatibility bölümünden log ve driver uyumsuzluklarını görebilir ve böylece bu tarz sorunların önüne geçebilirsiniz.

Eğer yukarıdaki uyarının hangi log’a göre bulunduğunu merak ediyorsanız Findings bölümüne giriş yapabilirsiniz. Bu bölümden KB’yi adresleyen logları görebilirsiniz. Burada yer alan saat aralığına göre, eğer isterseniz Log Inspector kullanarak logların detaylarınada bakabilirsiniz.

Log Inspector bölümüne giriş yapmak için Runecast’a login olduktan sonra Log Inspector butonuna basıyoruz.

Log Inspector bölümüne girdiğimizde karşımıza birden fazla log gelecektir. Burada yer alan search bölümünden belirli kelime öbeklerini aratabilir ve böylece log içerisinde bu kelimelerin geçip geçmediğine bakabilirsiniz. Örneğin ben yukarıda vmhba kelimesini aratıyorum. Bunu yapmamın sebebi aslında storage tarafında olumsuz sayılabilecek bir log var mı bunu kontrol etmek istememdir.

vmhba yazdığımda karşıma aşağıdaki gibi bir log geldi.

cpu1:131271)WARNING: NMP: nmp_DeviceRetryCommand:133: Device “mpx.vmhba1:C0:T0:L0”: awaiting fast path state update for failover with I/O blocked. No prior reservation exists on the device.

Karşınıza çıkan bu log içeriğini isterseniz internette araştırabilirsiniz. Ancak burada karşınıza gelen veriler eğer önemli ise aynı zamanda Log KBs Discovered bölümünde de yer alacaktır. Runecast sayesinde VMware altyapınız uçtan uca proaktif olarak izleyebilir ve sorunlarınız hızlı bir şekilde tespit edebilirsinz.

Runecast Vmware Analyzer – Türkiye Distribütör firması “OTD Bilişim” satış ekibi otd.salesgrp@onlineteknikdestek.com  ile iletişime geçebilirsiniz.

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/runecast-ile-vmware-upgrade-planlari-nasil-yapilir.html

Runecast ile VMware Upgrade Planları Nasıl Yapılır?

Merhaba,

Runecast ile VMware Upgrade Planları Nasıl Yapılır? isimli bu yazımda VMware ortamlarında upgrade planlarını Runecast ile nasıl yapabileceğinizi anlatacağım.

VMware ortamlarında upgrade işlemleri genellikle sorunlu olmuştur. Çünkü ESXi versiyonu donanım ile uyumlu olması gerekmektedir. ESXi Server bir işletim sistemidir. ESXi Server sayesinde donanım katmanında sanallaştırma yaparız. Yani fiziksel donanım üzerindeki CPU, Memory, Disk, Network gibi kaynakları sanallaştırırız. Böylece bu fiziksel sunucu üzerinde sanal sunucular yani virtual machine’ler açarız. Bundan dolayı bir ESXi Server kurarken ilerleyen süreçlerde sorunlar yaşamamak için driver ve firmware konularına çok dikkat etmemiz gerekiyor.

Daha önce Runecast’ı kullanmadıysanız veya ne işe yaradığını bilmiyorsanız aşağıdaki linki inceleyebilirsiniz.

Runecast Analyzer Nedir?

Runecast Analyzer

Runecast Kubernetes Ortamınızı Nasıl Analiz Eder?

Runecast ile VMware Upgrade Planları Nasıl Yapılır?

ESXi Server özelinde driver ve firmware oldukça önemli. Özellikle mevcut ESXi Server’in update ve upgrade süreçlerinde de driver ve firmware oldukça önemli rol oynuyor. Update ve Upgrade gibi süreçlerde fiziksel donanımın update veya upgrade yapacağınız sürüm ile uyumluluğuna da dikkat etmek gerekiyor. Eğer siz uyumsuz bir donanım üzerine kurulum yaparsanız sorun yaşamanızda olasıdır. Update ve Upgrade konuları her ne kadar basit kadar gözüksede özellikle büyük yapılarda karşımıza oldukça karmaşık bir süreç gibi çıkabilir.

Runecast, bu tarz büyük yapılarda bize oldukça kolaylık sağlıyor. Runecast sayesinde VMware altyapınızın update ve upgrade süreçlerini yönetebilirsiniz. Kullanmış olduğunuz donanımların uyumluluklarını, sizin seçeceğiniz ESXi Server versiyonuna göre simule edebilirsiniz.

Runecast ile VMware Upgrade Planları Nasıl Yapılır?

Runecast ile VMware Upgrade Planları Nasıl Yapılır? Runecast altyapınızda bulunuyor ise, sahip olduğunuz fiziksel donanımların uyumluluklarını tek tek araştırmaya gerek bulunmuyor. Yukarıdaki örnekte bir vCenter Server içerisinde yer alan bir donanımın uyumluluklarını görebilirsiniz. Dell Raid Controller’ın firmware versiyonunun uyumsuz olduğunu ve önerilen versiyonları aşağıda göstermektedir.

Ayrıca bu donanım’ın VMware HCL üzerindeki değerinide görebilirsiniz.

https://www.vmware.com/resources/compatibility/detail.php?deviceCategory=io&productid=39126&releaseid=518

Kullanmış olduğunuz donanım parçalarının VMware HCL üzerindeki linklerinede Runecast içerisinden ulaşabilirsiniz.

Farklı bir örneği değerlendirecek olursak, yukarıdaki örnekte HPE Smart Array’ın ESXi Server 7.0 U2 seçtiğimizde driver ve firmware uyumsuz olduğunu görüyoruz. Yine burada olması gereken minimum driver ve firmware versiyonlarının neler olması gerektiğide belirtiliyor. Dolayısıyla bu versiyona geçtiğinizde driver’larınız ESXi sürümü ile belki uyumlu sürüme gelebilir ancak firmware’in uyumsuz olacağını ve ekstra bir çalışma yapılacağını önceden biliyor olursunuz. Bunlar çok kritik ve önemli detaylardır. Çünkü burada yapacağınız bir hata ilerleyen aşamalarda virtual machine’lerinize sorun olarak geri dönecektir.

Runecast sadece driver ve firmware versiyonlarına bakmadığınıda belirtmek isterim. Kullanmış olduğunuz fiziksel sunucunun hangi ESXi versiyonunu desteklediğinide görebilirsiniz. Altyapınızda farklı donanım markaları ve modelleri kullanıyorsanız Runecast sayesinde basit bir şekilde uyumluluğu görebilirsiniz. Yukarıda mesela donanım’ın support edildiğini ancak BIOS versiyonunun support edilmediği görülmektedir. Uyumsuz BIOS versiyonu size performanssız ve sorunlu bir altyapı olarak geri dönüş yapar. Bundan dolayı BIOS versiyonunu sürekli güncel tutmamız gerekmektedir.

Tüm bu uyumluluk durumlarını isterseniz Excel’e export olarak alabilirsiniz. Açıkcası çok büyük bir altyapı yönetiyorsanız donanım satın alma işlemlerinizi bile Runecast üzerinden alacağınız veriler ile gerçekleştirebilirsiniz. Bir önceki makalemde de aslından bundan bahsetmiştim. Bu makaleme aşağıdaki linkten ulaşabilirsiniz.

Runecast 5.1 ile Gelen Yeni Özellikler

Runecast üzerinden elde edeceğiniz veriler ile hangi VMware ESXi Server sürümüne geçmeniz gerektiğini kolayca belirleyebilirsiniz. Altyapınızda yapılan değişiklikler ve bunların uyumlulukları ile ilgili anlık uyarılar alabilirsiniz. Şöyle düşünebilirsiniz. 100+ ESXi Server yönetiyorsunuz ve zaman zaman artan güvenlik açıklarından dolayı ESXi Server üzerinde patch/update/upgrade çalışması yapmak durumunda kalıyorsunuz. Böyle bir durumda çoğu zaman driver/firmware ve fiziksel sunucu uyumlulukları gözden kaçabiliyor.Gözünüzden kaçması durumunda daha ciddi sorunlar ile karşılaşabilirsiniz. Örneğin uyumsuz bir donanıma ESXi Server kurduğunuzda ve bir sorun yaşadığınızda, vendor’a destek için çağrı açmanız durumunda destek alamayabilirsiniz. Çünkü uyumsuz bir donanım ve ESXi Server kullanıyorsunuz. Altyapınızı yönetirken bu detayı lütfen gözden kaçırmayın.

Runecast Vmware Analyzer – Türkiye Distribütör firması “OTD Bilişim” satış ekibi otd.salesgrp@onlineteknikdestek.com  ile iletişime geçebilirsiniz.

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/runecast-kubernetes-ortaminizi-nasil-analiz-eder.html

Runecast Kubernetes Ortamınızı Nasıl Analiz Eder?

Merhaba,

Runecast Kubernetes Ortamınızı Nasıl Analiz Eder? isimli bu yazımda sizlere Runecast kullanılan ortamlarda Kubernetes yapılarını proaktif olarak nasıl analiz edildiğini anlatacağım.

Runecast ile ilgili daha önce yazmış olduğum makalelere aşağıdaki linkten ulaşabilirsiniz.

https://www.tayfundeger.com/?s=Runecast

Ayrıca Container mimari ile ilgili daha önce yazmış olduğum makaleleri inceleyebilirsiniz.

Docker mı VMware mi?

Docker Nedir?

Şirketinizin altyapısında kullanmış olduğunuz ürünler nekadar fazla olur ise bazı riskleri gözden kaçırmanız oldukça olasıdır. Bundan dolayı IT yöneticileri günlük rutin yaptığı çalışmaları otomasyona almaya çalışır. Günümüzde sanallaştırma oldukça yaygın olduğu için sanallaştırma ortamlarında oluşan sorunları ve güvenlik risklerini kolay bir şekilde takip edebileceğimiz ürünlerde oldukça sınırlı. Uzun bir süredir benimde kullanmış olduğum Runecast bizlere sanallaştırma altyapılarında oldukça kolaylıklar sağlıyor. Bu yazımda ise sizlere Runecast’ın Kubernetes ortamlarında bize hangi kolaylıkları sağladığı konusunda çeşitli bilgiler vereceğim.

Runecast Kubernetes Ortamınızı Nasıl Analiz Eder?

Kubernetes’i en basit hali ile anlatacak olursak, container üzerinde çalışan mikroservis tabanlı uygulamaların orkestrasyon işlemini gerçekleştiriyor. Yani sizin arka tarafta kullandığınız angular js’de uygulamanız olabilir ve arka tarafta mysql database’iniz olabilir. Kubernetes sayesinde database instance sayısını arttırabilir ve bunları orkestrasyon işlemini sağlayabilirsiniz. Kubernetes, container ortamındaki otomasyonu, orkestrasyonu sağlarken sunucunun dolaylı olarak network trafiğinide optimize edebiliyor.

Yani şöyle düşünün, kubernetes otomasyon ve orkestrasyon işlemlerini yaparken burada load balancing, storage yönetimi, kaynak yönetimi gibi işleride yönetiyor. Bir container’in nasıl ve nerede devreye girmesi gerektiğini yönetiyor.

Runecast ile birlikte Kubernetes’i ilk olarak 4.5 sürümünde duymaya başladık. Kubernetes altyapılarını tasarlarken cluster ve workload’ları güvence altına almak gerekir. Burada bir orkestrasyon işlemi yapıldığı için çok fazla değişken olacaktır. Bu süreç oldukça dikkat gerektiren süreçler olduğu için eğer 3 party bir üründen faydalanmıyorsanız bazı standartları gözden kaçırmanı oldukça olasıdır. Runecast sayesinde Kubernetes uygulamaları ve Center for Internet Security (CIS) uyumluluk standartları otomaitk olarak kontrol edilir ve olumsuz bir durum var ise bu size raporlanır.

Runecast sayesinde sanallaştırma ortamlarını proaktif olarak izlerken aynı zamanda Kubernetes altyapılarınıda proaktif olarak izleyebiliyoruz. Kubernetes Best Practices ‘lerine göre kritik sorunların ve düzeltilmesi gereken adımlarını Runecast üzerinde kolayca görebiliriz. Ayrıca mimarinizde oluşan güvenlik açıklarınıda basit bir şekilde görebilirsiniz.

Runecast Kubernetes Ortamınızı Nasıl Analiz Eder?

Runecast kullanıyorsanız Kubernetes altyapınızı basit bir şekilde kontrol edebileceğinizi söylemiştim. Runecast’a login olduktan sonra Best Practices bölümüne giriş yapıyoruz. Burada Products bölümünde yer alan Kubernetes seçeneğini seçerek Kubernetes ile ilgili Best Practices’lere aykırı olan bulguları karşımıza getiriyoruz.

Runecast Kubernetes Ortamınızı Nasıl Analiz Eder? Kubernetes kullanıyorsanız network tarafında yapacağınız izolasyonlara dikkat etmeniz gerekmektedir. Yukarıdaki örnekte Kubernetes objelerinde bir network policy’nin kullanılmadığı belirtiliyor. Ancak Kubernetes Best Practices’lerinde bunun kullanılması gerektiği belirtiliyor. Trafik akışını IP adresi veya port düzeyinde (OSI katmanı 3 veya 4) kontrol etmek istiyorsanız cluster’ınızda belirli uygulamalar için Kubernetes NetworkPolicies kullanmayı düşünebilirsiniz. Container mimarilerinde bu genellikle atlanan veya gözardı edilen bir konudur. Ancak bir saldırı veya atak durumunda bunların ne kadar önemli olduğunun farkına varırız.

Ayrıca Best Practices’e aykırı olan bu durumun cluster’da mı yoksa node’lar arasında mı olduğunu ayırca Findings bölümünden görebilirsiniz. Yani bunun güzel yanı aslında komple node ve cluster’lara kadar taramalar yapıp bunların özelinde uyumsuzlukları çıkartıyor.

Vulnerabilities bölümünde güvenlik açıklarını görebilirsiniz. Runecast birden fazla ürünü kontrol ettiği için yukarıda yer alan Products bölümünden Kubernetes’i seçmeniz gerekiyor. Kubernetes’i seçtiğimizde, Kubernetes ortamındaki güvenlik zaafiyetlerini görebilirsiniz. Yukarıdaki örnekte, CVE-2020-8554 ‘un güvenlik zaafiyetini görebilirsiniz. Kubernetes kullanan kişiler bilir bu güvenlik zaafiyeti ilk çıktığında çok konuşulmuştu. Çünkü bu açık sayesinde cluster’da yeni pod’lar oluşturabilir ve gelen trafiği izleyebilirsiniz.

Gördüğünüz gibi oldukça ciddi bir güvenlik zaafiyeti ancak Runecast kullanıyorsanız Kubernetes altyapınızda bulunan güvenlik zaafiyetlerini ayrıca düşünmenize gerek kalmıyor. Çünkü Runecast, Kubernetes’in güvenliği için CIS Benchmark’ı kapsayarak node düzeyinde ve cluster düzeyinde otomatik Kubernetes analizleri sunar. Runecast Analyzer , CIS 1.6.0’a karşı kontrollerin kapsamı ile CIS Benchmarks ile güvenlik uyumluluğunuzu proaktif olarak denetler . Ayrıca güvenlik açığı eşlemesi sağlar.

Kubernetes bulunan ortamlarda Configuration Vault özelliğini kullanabilirsiniz. Bu özellik sayesinde konfigurasyon farklılıklarını görebilir ve buna göre müdahalelerde bulunabilirsiniz. Yukarıdaki örnekte node’lar arasında bulunan kernel version farklılığını görebilirsiniz. Ayrıca burada CPU, Memory, Kubelet version, Pod sayısı, OS Image gibi değerleride görebilirsiniz. İlerleyen versiyonlarda muhtemelen Configuration Vault bölümünde daha fazla veri ile karşılaşırız diye düşünüyorum.

Kendi altyapınızda güvenli bir şekilde çalışan Runecast Analyzer, hem bulutta hem de şirket içinde neler olup bittiğine ilişkin öngörülerle Kubernetes altyapınız için güvenlik uyumluluğu kontrollerini otomatikleştirir. Bu durum altyapıya proaktif yaklaşmanızı ve her zaman kontrol altında tutmanıza olanak sağlar.

Runecast Vmware Analyzer – Türkiye Distribütör firması “OTD Bilişim” satış ekibi otd.salesgrp@onlineteknikdestek.com  ile iletişime geçebilirsiniz.

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/runecast-5-1-ile-gelen-yeni-ozellikler.html

Runecast 5.1 ile Gelen Yeni Özellikler

Merhaba,

Runecast 5.1 ile Gelen Yeni Özellikler isimli bu yazımda sizlere Runecast’ın yeni gelen versiyonu ile birlikte gelen yeniliklerden bahsediyor olacağım.

Daha önce Runecast’ı kullanmadıysanız veya ne işe yaradığını bilmiyorsanız aşağıdaki linki inceleyebilirsiniz.

Runecast Analyzer Nedir?

Runecast Analyzer

Runecast Kullanmanın Avantajları

Runecast 5.1 ile Gelen Yeni Özellikler

Runecast ile ilgili zaman zaman makaleler yazıyorum ancak bu süreçte Runecast kendini oldukça hızlı geliştirmeye devam ediyor. Geçtiğimiz zamanlarda makale yazdığımda Runecast’ın Nutanix support’unun olup olmadığı konusunda çok fazla soru geliyordu. Bu sorunuzu artık Evet! Olarak yanıtlayabilirim. Artık Nutanix AOS kullanıyorsanız Runecast ile ortamlarınızı analiz edebileceksiniz.

Runecast 5.1 ile birlikte gelen yenilikler hakkında kısaca bilgi vermek istiyorum.

Configuration Vault:

Configuration Vault özelliği aslında beni oldukça heyecanlandıran özelliklerden birtanesidir. Bu özellik sayesinde altyapımıza daha hakim olabiliriz.

Configuration Vault özelliği sayesinde VMware vSphere, VMware Horizon, AWS, Kubernetes, NSX, vCloud Director ve AWS gibi ortamlarda yer alan konfigurasyon verilerinin metaları Runecast’a kopyalanır. Bu veriler Runecast dashboard’ında karşınıza grafikler halinde sunulur. Configuration Vault’ın asıl amacı aslında altyapınızda yapılan değişiklikleri analiz etmenize yardımcı olmaktır.

Runecast 5.1 ile Gelen Yeni Özellikler

Bu özelliği biraz daha detaylandırmak istiyorum. 10 taneden az ESXi host’u bulunan firmalarda genellikle satın almalarda çok uğraşmazsınız. Ancak bir datacenter iseniz, altyapınıza yeni bir sunucu alımı yapmak istediğinizde büyüme raporlarına ihtiyacınız olacaktır. 2019 senesinde kaç virtual machine bulunuyordu, 2020’de kaç virtual machine’e ulaştık? 2019 senesinde datastore doluluk oranı neydi 2020’de ne kadar oldu gibi soruların cevaplarını bulabilirsiniz.

Aslında bu işlemleri VROPS üzerinden de gerçekleştirebilirsiniz ancak orada bu işlemleri gerçekleştirmek için kendiniz raporlar çıkarmanız gerekiyor. Bu raporları çıkarmak ve hazırlamak biraz sürenizi alıyor. Aynı şekilde Rvtools gibi raporlar ilede bunu yapabilirsiniz ancak Runecast size bu dataları günlük verirken Rvtools gibi ürünlerde sadece çalıştırdığınız günü baz alırsınız. Runecast bizlere tüm verileri tek bir ekranda günlük rapor şeklinde verebiliyor. Tüm bunlara ek olarak, ESXi hostlar arasındaki versiyon farklılığı, fiziksel sunucular arasındaki donanım ve firmware farklılığına kadar detayların hepsini tek bir ekranda görebilir ve bunları CSV formatında dışarı çıkarabilirsiniz.

Yukarıda örneği doğrudan VMware üzerinden verdim ancak, eğer bir AWS kullanıcısı iseniz, Eleastic IP, Load Balances, RDS Cluster, RDS Instance ve VPC’lerinde detaylarını görebilirsiniz. Yukarıda hangi ürünleri support ettiğini ayrıca belirttim zaten.

Configuration Vault özelliği sayesinde altyapınızda bulunan farklılıkları görebilir, böylece eğer bir sorun yaşıyorsanız bu sorunun konfigurasyon farkından mı kaynaklı sorusunun cevabını hızlı bir şekilde görebilirsiniz.

Remediation:

Runecast’ın üzerinde en çok uğraştığı aslında özelliklerden birtanesi Remediation özelliği diye belirtiliyor. Bende bunu anlattıktan sonra ne kadar güzel bir özellik olduğunuda kendiniz anlamış olacaksınız 🙂

Remediation, bir sorun tespit edildiğinde bu sorunun düzeltilmesine yardımcı olan harika bir özelliktir. Elbette şuanda tespit edilen sorunların hepsi otomatik olarak düzeltilemesede, ilerleyen sürümlerde bu kapsamın daha da ilerleyeceğini, yeteneklerinin artacağını düşünüyorum.

Remediation özelliği sayesinde altyapınızda oluşan bir hata veya bir konfigurasyon hatasını düzeltebilirsiniz. Örneğin ESXi Server üzerinde SSH’ı aktif duruma getirdiğinizde, Host üzerinde sarı bir ünlem çıkacaktır. Bunun sebebi aslında güvenlik açığından kaynaklanmaktadır. Zaten VMware Best Practices’lerini okuduğunuzda SSH’ı kullanmadığınızda disable etmeniz gerektiğini görürsünüz. 22 numaralı port SSH tarafından kullanıldığı için siz servisi başlattığınızda bu port üzerinden dışarıdan bağlantı sağlanabilecektir.

Bundan dolayı eğer kullanmıyor isek, SSH’ı stop durumda bırakmamız gerekmektedir. Ancak çok büyük ortamlarda maalesef bunun takibini yapmam mümkün olamayabiliyor. Eğer Runecast kullanıyorsanız Best Practices bölümünde karşınıza çıkan uyarılara müdahale edebilirsiniz. Yukarıda vermiş olduğum örnekte olduğu gibi SSH servisi start durumda ise karşınıza çıkan Remediation butonu ile bu servisi durdurabileceğiniz PowerCLI ve Ansible script’leri karşınıza çıkacaktır.

Runecast’ın Remediation özelliği gibi çalışan farklı bir ürün hakkında bilgi vermek istiyorum. vRealize Orchestrator aslında burada bahsedeceğim Remediation özelliği gibi işlemleri yapabiliyor. Orchestrator, VMware’in enfazla kullanılan ürünlerinden birtanesidir. Çünkü ayrı bir lisansa ihtiyaç duymaz ve vCenter Server lisansı ile birlikte gelir. Ancak ileri seviye scripting bilgisine sahip değilseniz Orchestrator ile çok fazla işlem yapamazsınız. Dolayısıyla hem kullanımı zor hemde ciddi bir know how gerektiren bir üründür. Ancak Runecast sayesinde basit bir şekilde sorunlarımızı çözebileceğiz.

Ben açıkcası Runecast 5.1 ile Gelen Yeni Özellikler Remediation özelliğini ileride daha kapsamlı olacağını düşünüyorum. İlerleyen versiyonlarda otomatik müdahale gibi işlemlerde olabilir. Biliyorsunuz VROPS’da actios diye bir tab ve buradan bazı müdahalelerde bulunulabiliyor. Ben bunun Runecast içinde geleceğini düşünüyorum. Yani bir süre sonra, eğer Runecast’a sahipseniz altyapınızı hiç izlemenize bile gerek kalmayabilir:)

Runecast Vmware Analyzer – Türkiye Distribütör firması “OTD Bilişim” satış ekibi otd.salesgrp@onlineteknikdestek.com  ile iletişime geçebilirsiniz.

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-thick-disk.html

vSAN ve Thick Disk

Merhaba,

vSAN ve Thick Disk isimli bu yazımda sizlere vSAN ortamlarında Thick disk kullanımından bahsedeceğim. Daha önce vSAN ile ilgili yazmış olduğum yazılara aşağıdaki linkten ulaşabilirsiniz.

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

vSAN ortamlarında Thin ve Thick disk kullanımları çeşitli bazı sorular geliyor. Bunun üzerine bu konu hakkında bir bilgilendirme yapmaya karar verdim. VMware vSAN ortamı kullanıyorsanız, oluşturduğunuz virtual machine’in disklerini default olarak Thin şeklinde tanımlayabilirsiniz. Thin disk ve Thick arasındaki fark için aşağıdaki makalemi inceleyebilirsiniz.

Thin disk mi Thick disk mi?

vSAN ve Thick Disk

Yukarıda belirtmiş olduğum makale VMFS formatında bulunan datastore’lar için geçerlidir. Yani VMFS bir datastore kullanıyorsanız, üreticilerin önermiş olduğu disk çeşitlerini kullanabilirsiniz. Örneğin bir SQL Server kurulumu yapacaksınız ve SQL Server’in Best Practices dökümanlarını incelediğinizde Eager Zeroed Thick disk kullanılmasının önerildiğini göreceksiniz. Bunun sebebi aslında VMFS’in meta dataları yazmak zorunda kalmayacağı ve böylece performans artışı sağlamasından kaynaklanmaktadır. Thick verilmiş bir disk oluşturulması, IO yazımı sırasında bloğun tahsis edilmesi ve sıfırlanması ihtiyacını ortadan kaldırır. VMFS ile vSAN Datastore’lar arasında farklılıklar bulunmaktadır. VMFS datastore’un bulunduğu ortamda virtual machine’de farklı özellikler kullanabilirken, vSAN datastore’larında farklı özellikler kullanabilirsiniz.

Bir vSAN datastore’unda tüm write işlemleri ilk olarak cache katmanında gerçekleşir ve bu blok cache disk’ine yazıldığında hemen onaylanır, devamında kapasite diskine gönderilir. Bu aşamadan sonra Storage Policies üzerinde belirlemiş olduğunuz RAID dizilimine göre veriler kapasite katmanında çoğaltılır ve bu esnada hiç bir performans farkı görülmez.

Eğer bir vSAN ortamı kullanıyorsanız EZT yani Eager Zeroed Thick disk için konfigurasyon yapılamadığını görebilirsiniz. Bunun sebebi vSAN’ın yapısal farklılıklarından kaynaklanmaktadır. vSAN ortamında oluşturulan disk tiplerinin bir önemi bulunmamaktadır. Thin veya Thick oluşturulmasının vSAN özelinde bir farkı bulunmamaktadır. vSAN ile birlikte kullandığımız Storage Policies ayarlarında Object Space Reservation (OSR) adı verilen bir ayar bulunmaktadır. OSR değeri 0 olduğunda thin disk, 100 ayarlandığında ise Thick disk olarak kabul edilir.

vSAN ve Thick Disk

OSR değerini, kapasite ayırmak istediğiniz bir cluster ortamında yani provisioned space gibi değerlerin üzerine çıkmasını önlenmesinin istediği durumlarda kullanabilirsiniz. OSR seçeneği sadece kapasiteyi yüzdesel olarak ayırma yöntemidir. Lazy-Zeroed Thick Provisioned disklere benzer şekilde davranır. OSR üzerindeki konfigurasyon Eager Zeroed Thick değildir. Default olarak Thin provisioning seçeneği seçili geldiği için kaynakları daha efektif bir şekide kullanabiliriz. Eğer siz burada Thick seçeneği ile devam ederseniz Deduplication’dan faydalanamayacağınızı belirtmek isterim. Normal şartlarda bir vSAN ortamında Deduplication ve Compression etkinleştirilir, çünkü ortamın bir depolama kapasitesi açısından olabildiğince verimli olması gerekir. Bir vSAN datastore’u içindeki tüm VM’leri thick olarak olarak kullanmak, aslında vSAN’ın diskteki verileri deduplication ‘a izin vermeyeceğiniz anlamına geldiğinden, thick provisioned kullanımı bu tasarım hedefiyle doğrudan çelişir.

vSAN ortamlarında eğer yukarıda belirtmiş olduğum şartları kabul ederseniz elbette Thick disk kullanabilirsiniz ancak EZT için özel bir konfigurasyon yapamazsınız. Aslında buna gerekte bulunmaz. Yukarıda da belirttiğim Thick veya Thin olmasının vSAN özelinde hiç önemi bulunmamaktadır. Çünkü vSAN tüm diskleri Thin olarak kabul eder. Eğer ortamınızda Fault Tolerance veya Shared disk yani Oracle RAC, SQL gibi ürünler var ise OSR üzerinden gerekli konfigurasyonları yapabilirsiniz. Oracle RAC‘ın vSAN üzerindeki konfigurasyonu için aşağıdaki linki inceleyebilirsiniz.

https://kb.vmware.com/s/article/2121181

vSAN, esneklik ve performans göz önünde bulundurularak tasarlanmıştır. Bir vSAN ortamında Storage Policies üzerinde thick provisioning’in bulunmasıının performans açısından gerekli değildir. Yani bu seçeneği kullanmanız durumunda daha yüksek bir performans ile karşılaşmazsınız. Aksine vSAN’ın bizlere sunmuş olduğu deduplication gibi faydalarıda ortadan kaldırır. vSAN ortamlarında kapasite ve verimlilik çok önemil olduğu için Thick disk kullanımının bir faydası bulunmamaktadır. Eğer VMware vSAN ortamlarını yöneten bir IT uzmanınız bulunmuyor veya organizasyonel bazı sebeplerden dolayı kapasiteyi düzgün yönetemiyorsanız o zaman OSR üzerinde Thick Provisioning seçeneğini açıp kullanabilirsiniz. Bunun haricinde hiç bir şartta bu seçeneği değiştirmenizi tavsiye etmiyorum. Yani default Thin olarak bırakmanızı öneririm. İlerleyen makalelerde Thick verilen bir disk’in nasıl tespit edileceğini ve bunun nasıl thin diske çevrileceği konusunda da bilgi vereceğim.

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/virtual-machine-hard-stop.html

Virtual Machine Hard Stop

Merhaba,

Virtual Machine Hard Stop isimli bu yazımda sizlere vSphere 7 ile birlikte gelen yeni bir özelliğin kullanımı hakkında bilgi vereceğim. vSphere 7 ile birlikte bir virtual machine üzerinde sağ click yaptığımızda Power bölümü altında Kill butonu bulunmaktadır. Bu butonu ne zaman ve nasıl kullanmalıyız?

Daha önce yazmış olduğum vSphere 7 ile birlikte gelen yeniliklere aşağıdaki linkten ulaşabilirsiniz.

vSphere 7 Yenilikleri

Virtual machine yönetimini sağlarken bazı durumlarda hang gibi sorunlar ile karşılaşabilirsiniz. Böyle bir durumda ilk olarak virtual machine’i reboot etmeniz veya resetlemeniz gerekir. Bunu yapmak istediğinizde virtual machine askıda kalabilir. Yani sizin reboot veya reset komutlarınıza cevap veremeyebilir. Böyle bir durumda virtual machine’i kill etmeniz gerekebilir.

Esxtop üzerinden virtual machine kill edilmesi

Ben daha önce virtual machine kill işleminin nasıl yapılacağını yukarıdaki linkte anlatmıştım. vSphere 7 ile birlikte artık ESXTOP üzerinden virtual machine ‘i killet etmenize gerek bulunmuyor.

Virtual Machine Hard Stop

vSphere 7 ile birlikte gelen Hard Stop özelliği sayesinde bir virtual machine hang olduğunda yani vCenter Server üzerinden power off/power on/restart/reset operasyonlarına cevap vermediği durumlarda artık ssh üzerinden ESXi’a bağlanıp process kill etmemize gerek bulunmayacaktır. vCenter Server üzerinden işlem yapmak isteyeceğiniz virtual machine’i seçip Hard Stop butonuna basmanız yeterli olacaktır. Hard Stop butonuna bastığınızda virtual machine üzerinde çalışan tüm işlemler zorla sonlandırılır ve bunun sonucunda virtual machine power off duruma getirilir. Hard Stop sayesinde virtual machine ‘e ait process’ler kill edileceği için OS bazında veri kaybı gibi durumlar ile karşılaşabilirsiniz. Bundan dolayı bu seçeneği yanlızca ihtiyacınız olan durumlarda yapmanız gerekmektedir.

Hatta bazı durumlarda virtual machine’e komut gönderdiğinizde aşağıdaki hata ile karşılaşabilirsiniz. Bu gibi durumlarda da Hard Stop komutunu kullanabiliriz.

Another task is already in progress,

Bu seçeneği yanlızca virtual machine’in vCenter Server üzerinden göndermiş olduğunuz komutlara cevap vermemesi durumunda kullanmalısınız.

Virtual Machine Hard Stop

Power off/power on/restart/reset komutlarına cevap vermeyen virtual machine üzerinde sağ click Power > Hard Stop butonuna basıyoruz.

Bu işlemi yaptığımızda karşımıza bir uyarı çıkıyor ve OK butonu ile işlemi başlatıyoruz.

Hard Stop işlemi başarılı bir şekilde tamamlandığında virtual machine power off duruma gelecektir. Bundan sonra artık virtual machine’i power on edebilir ve tekrar kullanmaya başlayabilirsiniz.

Virtual machine’in task/event bölümünü incelediğinizde virtual machine’de yapılan Hard Stop işleminide görebilirsiniz.

Son olarak, en baştada belirttiğim gibi Hard Stop işleminin yalnızca virtual machine’in hang olduğu ve komutlara cevap vermediği durumlarda kullanmanız gerektiğini unutmayın.

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-disk-balance.html

vSAN Disk Balance

Merhaba,

vSAN Disk Balance isimli bu yazımda sizlere vSAN ortamında karşılaştığımız Disk Balance uyarısı hakkında detaylı bilgi vereceğim. Daha önce vSAN Automatic Rebalance ile ilgili bir yazı yazmıştım. Bu yazıma aşağıdaki linkten ulaşabilirsiniz.

VSAN Automatic Rebalance

vSAN ortamı kullanıyorsanız, maintenance veya ESXi host’un down olması gibi durumlardan sonra, Cluster Summary’de aşağıdaki gibi bir uyarı ile karşılaşabilirsiniz.

Warning: Virtual SAN Disk Balance

vSAN ortamında bulunan bir ESXi host’u Evacuate all data seçeneği ile maintenance’a almanız durumunda vSAN node’u üzerindeki datalar farklı hostlara taşınacağı için node’lar üzerinde disklerde eşit yükler bulunmaz. Tabiki bu senaryoyu daha fazla genişletebilirsiniz. Zaten makalemin ilerleyen bölümlerinde buna yer vereceğim.

vSAN Cluster’ında herhangi bir ESXi host üzerindeki disk/disk grupları %80 dolabilir. Böyle bir durumda vSAN, doluluk yaşanan disk veya disk grubunda bu alanı %80’in altına düşene kadar cluster’i otomatik olarak dengeler. Burada %80 diye belirtiyorum ancak bu değer Rebalance işlemlerini manuel veya automatic yapmasanız bile %80 eşiğine geldiğinde otomatik olarak yapılır. Ayrıca isterseniz bu değeri değiştirebilirsiniz. Bu işlem yapılırken performans sorunları yaşayabilirsiniz. Performans sorunları derken, vSAN cluster’ınızda virtual machine çalışamayacak düzeyde bir performans sorunundan bahsetmiyorum 🙂 Disk rebalance işlemi, vSAN cluster’ınızın I/O performansını etkileyebilir. Bu performans etkisinden kaçınmak için automatic rebalance işlemini, altyapının yoğun olarak kullanılmadığı gün/saatlerde aktif edebilirsiniz.

vSAN Disk Balance

Daha önce yukarıda belirtmiş olduğum makale içerisinde de belirtmiştim ancak tekrar belirtmek istiyorum. Aşağıda belirteceğim işlemler disk kapasitelerinin %80 ‘e ulaşmasına ve rebalance işleminin başlamasına sebep olabilir.

Cluster’da donanım arızası olabilir.

vSAN ESXi host’ları Evacuate all data seçeneği seçilerek maintenance mode’a alınır.

FTT=0 olarak konfigure edilmiş bir vSAN cluster’ınız var ve Ensure data accessibility modu ile maintenance mode’a alınır.

Yukarıdaki durumların oluşması durumunda rebalance işlemi başlar.

Rebalance işlemini 2 farklı şekilde yapabilirsiniz. Ancak burada kullanmış olduğunuz versiyon önemli rol oynuyor.

Proactive Rebalance: vSAN 6.7 U2 ve daha eski bir sürüm kullanıyorsanız, Disk Balance uyarısını gördüğünüzde vSAN Health bölümüne giriş yapabilir ve buradan manuel olarak Proactive Rebalance işlemini gerçekleştirebilirsiniz.

Automatic Rebalance: vSAN 6.7 U3 veya daha yeni bir sürüm kullanıyorsanız, Disk balance uyarısını gördüğünüzde eğer Automatic Rebalance özelliği aktif durumda ise bu işlem otomatik olarak gerçekleştirilir.

vSAN Disk Balance

Öncelikle vSAN 6.7 U2 ve daha eski bir sürüm kullanıyorsanız Proactive Rebalance kullanmanız gerekiyor. Bunun için Monitor > vSAN > Health bölümüne giriş yapmanız gerekiyor. Bu bölüme giriş yaptığınızda karşınıza zaten vSAN Disk Balance warning’i ile karşılaşacaksınız. Bu bölümde Proactive Rebalance Disks butonuna bastığınızda işlem başlayacaktır.

ilk 30 dakika boyunca herhangi bir ilerleme göremeyebilirsiniz. Bunun nedeni, VSAN’ın herhangi bir nesneyi hareket ettirmeden önce dengesizliğin devam ettiğinden emin olmak için beklemek istemesidir. Sonuçta, yeniden dengeleme görevi nesneleri diskler/node’lar arasında taşımaktır. Bu işlem network üzerinden veri kopyalama işlemi yaptığı için, data’nın büyüklüğüne göre bant genişliği ve zaman gerektirir. Bu işlem 24 saat sürebilmektedir. 24 saat sonrasında otomatik durdurulacaktır. Ancak tekrar belirtmek istiyorum, bu işlemi minimum iş yükü olduğunda yapmanız tavsiye ediliyor.

vSAN 6.7 Update 3 ve sonraki versiyonları kullanıyorsanız artık Proactive Rebalance işlemini yapmanıza gerek bulunmuyor. Ancak Automatic Rebalance ‘i öncelikle aktif etmeniz gerekiyor. Bunun için isterseniz yukarıdaki ekrandaki gibi Configure Automatic Rebalance butonuna basabilirsiniz. İsterseniz de Cluster’ı seçtikten sonra Configure > vSAN > Services > Advanced options bölümüne girebilirsiniz.

Advanced Options bölümüne girdiğinizde Automatic Rebalance butonunu göreceksiniz. Default olarak bu seçenek disable durumda gelir. Automatic Rebalance ‘i aktif duruma getirdiğinizde hemen altında Rebalance Thereshold yüzdesi belirtebilirsiniz. Burada belirteceğiniz değerin üzerine disk üzerindeki veri miktarı çıktığında otomatik olarak rebalance işlemi başlar. Siz bu değeri istediğiniz gibi değiştirebilirsiniz.

Önemli: Rebalancing Thereshold değerini default olan %30 değerinde tutun. Bu değerin düşürülmesi, rebalance trafiğinin miktarını artırabilir ve hiçbir işlevsel fayda olmaksızın gereksiz yeniden rebalance’a neden olabilir.

Ancak şunu belirtmek istiyorum. Yukarıda da belirtmiştim aslında. Eğer diskler üzerindeki doluluk %80’e ulaştığında Automatic Rebalance aktif olmasa bile otomatik olarak rebalance işlemine başlanır. Yani %80 üzerine disk doluluğu çıktığında siz hiç bir işlem yapmasanızda, automatic rebalance aktif olmasada arka planda rebalance yapılır.

Rebalance işlemleri sadece disk grupları üzerinde yapılır. Yani, automatic rebalance’i cluster üzerinden aktif ediyorsunuz ancak sadece belirtilen eşik değerleri üzerinde bulunan ESXi hostlar üzerinde bu işlem gerçekleştirilir. Yani komple cluster üzerindeki tüm ESXi host’lar üzerinde bu işlem yapılmaz. Diskler veya disk grupları üzerindeki veriyi sadece ihtiyacı kadar hareket ettirecektir.

vSAN Cluster’ınızda automatic rebalance özelliğini etkinleştirmeniz önerilir. Özellik 6.7 U3’e eklendiğinde, VMware bu özelliği müşteri ortamlarına yavaş yavaş tanıtmak istedi ve vSAN 7’de bu şekilde kalmaya devam etti.

Daha öncede belirttiğim gibi, cluster üzerinde automatic rebalance’i geçici olarak devre dışı bırakmak isteyebileceğiniz birkaç nadir durum olabilir. Kısa bir süre içinde mevcut bir cluster’a çok sayıda ek ESXi host eklemek, bu olasılıklardan biri ve belki de testler için kullanılan nested vSAN ortamları olabilir. Ancak bunun dışında çoğu durumda, automatic rebalance etkinleştirilmelidir.

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-capacity-reserve.html

vSAN Capacity Reserve

Merhaba,

vSAN Capacity Reserve isimli bu yazımda sizlere, vSAN’ın yeni özelliklerinden biri olan vSAN Capacity Reserve hakkında detaylı bilgi vereceğim. Daha önce yazmış olduğum vSAN makalelerine aşağıdaki linkten ulaşabilirsiniz.

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

Daha önceki makalelerimde sürekli belirtmiştimdir. vSAN kullanıyorsanız doluluk oranlarına dikkat etmeniz gerekiyor. Kapasitenin %25 veya %30 ‘unu boş bırakmanız gerekiyor. Bunun sebebi aslında hem rebuild işlemleri hemde policy üzerinde yapacağınız bir değişiklikte free alan’ın azalmasına sebep olmasından kaynaklanıyor. vSAN rebuild, repair gibi işlemlerde free alanı kullanır. Hatta bu konu ile ilgili yazmış olduğum yazılara aşağıdaki linkten ulaşabilirsiniz.

VSAN – Resyncing Objects

SAN ve Arıza Senaryoları

VSAN – Advanced Options

vSAN Capacity Reserve

vSAN cluster’ında bir ESXi host’un down duruma gelmesi durumunda rebuild işlemi başlayacağı için bu free kapasite kullanılır. VSAN 7 U1’den önceki sürümlerde, önerilen free space’in takip edilmesi için vCenter Server alarm’larından veya vROPS gibi ürünlerden faydalanmak zorunda kalıyoruz. vSAN 7 U1 den itibaren artık bu free space’i özel olarak takip etmemize gerek bulunmuyor. vSAN ile birlikte gelen Reserved Capacity özelliği sayesinde,  kapasitenin kritik değerleri aşmasını önlenmesine olanak sağlıyor.

Yukarıda da belirttiğim gibi rebuild ve repair işlemleri için free space kullanılırken, Storage Policy üzerinde değiştireceğiniz bir object konfigurasyonundan kaynaklı free space’i de kullanabilirsiniz. Örneğin disk kopyasını değiştirmeniz durumunda free space’de değişim olur. Çünkü var olan virtual machine’in disklerinin farklı bir diske senkronize olurken free space’in bir miktarını kullanır. Free space’i etkileyen bu şekilde etkenler bulunuyor iken, reserved capacity tam burada işimize yarıyor.

vSAN Capacity Reserve aktif etmenin 2 farklı yolu bulunuyor. İsterseniz vSAN cluster’ını seçip Configuration > vSAN Services Enable Capacity Reserve butonuna basabilirsiniz. İsterseniz de Monitor > Capacity bölümüne giriş yaptığınızda aşağıdaki bir ekran ile karşılaşırsınız.

vSAN Capacity Reserve

Burada, You can enable operations and host rebuild reserve yanında yer alan Configure butonuna basıyoruz.

Enable Capacity Reserve bölümüne giriş yaptığımızda karşımıza 2 adet seçenek çıkıyor.

Operations reserve: vSAN’ın cluster’daki internal işlemlerini yürütmek için ihtiyaç duyduğu alanı görüntüler . Kullanılan alan işlem eşiğini aşarsa, vSAN düzgün çalışmayabilir. Örneğin storage policy üzerinde bir ayar değiştirceksiniz ve bu değiştirdiğiniz ayar sonucunda vSAN cluster’ı içerisinde bulunan virtual machine dosyalarının senkronizasyon edilmesi gerekecek. Bu gibi durumlarda Operations reserve seçeneğini aktif durumda olur ise altyapımızı riske atmadan sorunsuz bir şekilde işlemlerimize devam edebiliriz.

Host rebuild reserve: Host rebuild reserve ise, bir ESXi host’un kapasitesine göre ayarlanmıştır. Bir vSAN Cluster’ında bir ESXi host arızalanırsa veya down olursa diyelim, böyle bir durumda üzerindeki diskleri kullanamaz ve bundan dolayı vSAN cluster’ındaki depolamaya katkıda bulunamaz. Bu gibi durumlar oluştuğunda cluster’da repair/rebuild işlemleri başlanır. Bu konu ile ilgili yazmış olduğum makalelere yukarıdaki linkten ulaşabilirsiniz. Rebuild/Repair işlemlerinin yapılabilmesi için bir kapasiteye ihtiyaç bulunmaktadır. Eğer bu kapasite bulunmaz ise rebuild/repair işlemleri başarısız olablir. Host rebuild reserve sayesinde bu gibi kapasite ihtiyaçlarını kontrol etme imkanına artık sahibiz. Bu özellik default olarak devre dışıdır. Özelliği aktif edebilmek için Operations reserve’i ilk olarak aktif etmeniz gerekmektedir.

Capacity Reserve’i aktif etmezseniz, kapasitenin tükenmesi durumunda virtual machine’lerin oluşturulmasını veya virtual machine’lerin çalışması engellenir. Capacity Reserver’i aktif ederseniz, vSAN eşik sınırlarına ulaştıktan sonra bile virtual machine’den gelen IO talepleri karşılanmaya devam eder. Capacity Reserve etkinleştirdikten sonra, cluster’daki disk alanı, sağlık uyarılarını ve kapasite kullanımını izlemeli ve kapasite kullanımını eşik sınırlarının altında tutmak için uygun eylemleri gerçekleştirmelisiniz.

Bu özelliği kullanabilmeniz için bazı gereksinimleri karşılamanız gerekiyor. Capacity Reserve’i; Stretched Cluster, fault domain, ROBO Cluster ve vSAN Cluster’ı 4 node’dan az ise bu özelliği kullanamazsınız. Ayrıca vSAN Cluster’ında eşik değerinden yüksek bir kapasiteye sahipse zaten Capacity Reserve’i aktif edemezsiniz.

vSAN ‘ın yeni sürümleri ile birlikte sürekli yeni özellikler gelmeye devam ediyor. Capacity Reserve özelliğide vSAN ortamımı hem güvenli bir şekilde yönetmemize hemde operasyonel işlemler için gerekli tahmini boş kapasitenin dinamik olarak hesaplanmasını sağlıyor. Ayrıca cluster’ın kritik kapasite koşullarını aşmasını önlemeye yardımcı olduğu gibi güvenlik ve sağlık kontrollerinide kullanılmasına olanak tanıyor. vCenter Server üzerinden kritik kapasite koşullarını aşmasını önlemeye yardımcı olması oldukça güzel bir özellik. Çünkü yukarıda belirtmiş olduğum gibi ESXi host’un down olması durumunda gerekli olan rebuild işlemlerinde kullanılacak kapasiteyi hesaplaması önemli. Manuel olarak hesaplamak isteseniz farklı parametreleri toplamanız gerekir.

Bu özelliğin default olarak devre dışı geldiğini tekrar belirtmek isterim. Eğer free kapasitesiniz yeterli seviyede ise, yani %90 kullanım oranı bulunmuyor ise bu özellikleri aktif hale getirebilirsiniz.

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/scalable-shares-nedir.html

Scalable Shares Nedir

Merhaba,

Scalable Shares Nedir isimli bu yazımda sizlere vSphere 7 ile birlikte gelen yeniliklerden olan Scalable Shares hakkında detaylı bilgi vereceğim. vSphere 7 ile birlikte DRS ‘de çeşitli iyileştirmeler yapıldı. Daha önce vSphere 7 DRS yenilikleri ile ilgili çeşitli bilgiler vermiştim. Bu yazıma aşağıdaki linkten ulaşabilirsiniz.

vSphere 7 DRS Yenilikleri

Aslında yukarıdaki makalemde de kısaca bahsetmiştim ancak bu yazımda biraz daha detaylı olarak anlatacağım. Scalable Shares aslında vSphere DRS’in bir parçasıdır. Cluster ayarlarına girdiğinizde Scalable Shares seçeneğini görebilirsiniz. Peki Scalable Shares seçeneğini ne zaman kullanmalısınız?

Scalable Shares ‘i Cluster seviyesinde aktif edebildiğiniz gibi isterseniz Resource Pool seviyesinde de aktif edebilirsiniz. Resource Pool’un ve Shared değerlerinin ne olduğunu bilmiyorsanız aşağıdaki makalemi inceleyebilirsiniz.

Neden Resource Pool Kullanılır?

CPU/Memory/Disk Shares Değerleri

Share değeri ile ilgili ekstra olarak bilgi vermeyeceğim. Eğer bilmiyorsanız yukarıdaki linkten detaylı bilgi alabilirsiniz:) vSphere Cluster’ınızda bir resource pool oluşturduğunuzda, bu resource pool’un önem durumuna göre Share değerlerinde ayarlamalar yaparsınız. Örneğin yüksek öncelikli bir Resource Pool’un CPU Share değerini High (8000) olarak ayarlayabilirsiniz. Shares değerini Normal (4000) olarakta ayarlayabilirsiniz. Bu tamamen sizin bu Resource Pool altında barındıracağınız virtual machine’lerin önem sırasına göre değişkenlik gösterir. Bizler Resource Pool’u neden oluşturuyoruz? Çünkü önemli olarak gördüğümüz production ortamında bulunan sunuculara kaynak önceliği sağlamak ve olası bir kaynak yetersizliğinin önüne geçmek için çoğunlukla kullanırız. Dolayısıyla siz burada her bir virtual machine için tek tek kaynak rezervasyonu veya kaynak önceliği (shares) gibi değerleri değiştirmek durumunda kalmazsınız. Bunların hepsini Resource Pool üzerinden gerçekleştirebilirsiniz.

Scalable Shares Nedir

Yukarıda örnek vermiş olduğum shares değerine geri döneceğim. Normal ile High share değerleri arasında 2:1 oranı bulunmaktadır. Örneğin;  bir Cluster’da her biri 2 vCPU ve 32 GB olan 8 Virtual Machine bulunmaktadır.. Toplam Cluster’ımızda 100Ghz ve 100GB memory kaynağımız olduğunu düşünelim. Vermiş olduğum rakamlara göre elimizde var olmayan bir kaynağı veriyoruz. Çünkü Cluster’ın toplam kapasitesi 100GB iken, bizim Virtual Machine’lere vermiş olduğumuz toplam memory miktarı 256GB. High Shares bulunan Resource Pool’da 6 Virtual machine ve Normal Shares değerine sahip Resource Pool’da 2 Virtual Machine bulunmaktadır. Bir kaynak yetersizliği olursa, Cluster kaynaklarının 2 / 3’ünü High Shares değerine sahip Resource Pool’a ve cluster kaynaklarının 1 / 3’ünü Normal Shares değerine sahip Resource Pool’a verir.

Tüm Virtual machine’ler % 100 kullanım yapıyor ise, High Shares değerine sahip Resource Pool 66 GHz ve 66 GB memory hakkına sahip olur, Normal Shares değerine sahip Resource Pool ise 33 GHz ve 33 GB memory alır. Şimdi bu örneğe göre biraz daha detaylandıralım konuyu. HighShares değerine sahip Resource Pool’ da 6 Virtual Machine’in her biri, cluster kaynaklarının 2 / 3’ünün 1 / 6’sını alıyor. Başka bir deyişle, 66Ghz ve 66GB yani Virtual Machine başına 11 GHz  ve 11 GB yani kaynağın %16’sı. Normal Shares değerindeki Resource Pool’da ise 2 Virtual Machine’in cluster kaynaklarının 1 / 3’ünü alırken Virtual Machine başına 33 GHz ve 33 GB’in % 50’si oluyor. Yani 16 GHz ve 16 GB.

Yani bizim durumumuzda, Normal Shares toplamın 1 / 3 alacak ve High Shares seçeneği toplamın 2 / 3 alacaktır. Her iki Resource Pool’da aynı sayıda Virtual Machine olsaydı hiç bir sorun olmayacaktı 🙂

Sonuç olarak, Normal Shares değerine sahip bir Resource Pool’un, High Shares değerine sahip Resource Pool’a göre daha avantajlı olduğunu göreceksiniz. Eğer shares değeri yüksek Resource Pool içerisinde farklı shares değerlerine sahip Resource Pool’a göre daha fazla Virtual Machine var ise bu bir sorundur.

Buradan şu yorumu yapabilirsiniz aslında Resource Pool içerisinde kaynaklar static shares değerlerine göre hesaplanıyordu. Ancak Scalable Shares değeri ile birlikte dinamik bir yapıya geçmiştir. Scalable Shares ‘i aktif ettiğinizde Resource Pool içerisindeki Virtual Machine sayısıda kullanılarak bir hesaplama yapılır. Bundan dolayı yukarıda örnekte vermiş olduğum gibi Normal değerine sahip ve daha az Virtual Machine bulunan bir Resource Pool, High Shares değerine sahip bir Resource Pool’a göre daha fazla kaynak kullanabilir.

Scalable Shares Nedir

Scalable Shares Nedir

Scalable Shares ‘i 2 farklı şekilde aktif edebilirsiniz.

Cluster seviyesinde: Cluster üzerinden Scalable Shares ‘i aktif ettiğinizde bu cluster altında bulunan tüm Resource Pool’larda geçerli olur.

Resource Pool seviyesinde: Spesifik olarak belirli Resource Pool’lar üzerinde de aktif hale getirebilirsiniz.

Cluster seviyesinde Scalable Shares’i aktif hale getirdiğinizde  tüm Resource Pool’lar üzerinde Scalable Shares değeri aktif olarak gelir.

Sonuç olarak şunları söylemek istiyorum. Scalable Shares Nedir isimli bu yazımda bu değeri ve Resource Pool altında yer alan Shared değerleri yanlızca kaynak yetersizliği olduğu durumlarda devreye giren özelliklerdir. Daha önceki makalelerimde zaten bunu belirtmiştim. Eğer sizin cluster’ınızda bulunan ESXi host’ların kaynak kullanımları %100 duruma geldi ise ve Virtual Machine’ler artık kaynak ihtiyaçlarını karşılayamıyor ise ancak bu durumda shares değerlerinin önemi ortaya çıkar. Eğer sizin ortamınızda bir kaynak yetersizliği veya anlık dahi olsa CPU / Memory kaynaklarını %100 kullanma gibi bir durum yok ise zaten çok bir etkisi bulunmuyor.

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-ariza-senaryolari.html

vSAN ve Arıza Senaryoları

Merhaba,

vSAN ve Arıza Senaryoları isimli bu yazımda sizlere vSAN altyapılarında oluşabilecek hatalardan ve bu hataların sonucunda ne gibi sorunlar ile karşılaşacağınızdan bahsedeceğim.

Daha önce vSAN ile ilgili yazmış olduğum makalelere aşağıdaki linkten ulaşabilirsiniz.

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

Daha önce vSAN ile ilgili bir çok makale yazdım ancak disk arızaları ve hata senaryoları ile ilgili detaylı bir makale yazmadığımı farkettim. Bu yazımda vSAN ortamında cache ve data disklerinin bozulması durumunda oluşabilecek sorunlarada anlatacağım.

vSAN ve Arıza Senaryoları

Bu makaleyi okumadan önce aşağıda belirteceğim makaleleri okumanızı tavsiye ederim.

VSAN Disk Groups

VSAN Automatic Rebalance

VSAN – Advanced Options

Bir ESXi host vSAN içinde bir disk arızalanırsa ve hata kodları vSAN tarafından tespit edilirse, etkilenen tüm bileşenler bozulmuş olarak işaretlenir ve vSAN, bunu yapmak için mevcut kaynaklar varsa verilerin yeni bir kopyasını oluşturmaya çalışır. Kullanılabilir kaynak yoksa, arıza çözülene kadar bekleyecektir. Bu süre boyunca, bu hatadan etkilenen sanal makineler hala kullanılabilir olacak ve çalışmaya devam edecektir. Cache disk’i arızalanırsa, vSAN tüm disk grubunu bozulmuş olarak işaretler.

Bir disk uyarı vermeden arızalanırsa (hata kodu algılanmazsa) vSAN, altyapıda bulunan tüm etkilenen bileşenleri yok olarak işaretler ve 60 dakikalık bir delay timer başlatılır. Delay timer diye bahsettiğim aslında Resyncing Objects işlemi. Bir diskin bir ESXi host üzerinden yanlışlıkla çıkarıldığı ve diskin bu zaman penceresi içinde geri yerleştirilmesi durumunda, bileşenlerin yeniden senkronize edildiği ve bir vSAN’ın normal şekilde devam ettiği bir senaryo olabilir. 60 dakikalık delay timer süresi dolarsa, yok olarak işaretlenen bileşenler, cluster’da bulunan diğer host’larda yeniden oluşturulur. Tabi burada yeterli kaynak olduğunu varsayıyorum.

Bu konu ile ilgili aşağıdaki makalemi inceleyebilirsiniz.

VSAN – Resyncing Objects

Genel bir giriş yaptıktan sonra minimum konfigurasyon ile hata senaryolarını incelemeye başlayalım.

vSAN Hata Senaryoları:

vSAN ve Arıza Senaryoları

Şimdi, yukarıdaki 1 numaralı senaryoya baktığımızda 1 tane SSD cache bulunuyor ve 6 tane diskten oluşan bir disk grubuna bağlı durumda. Böyle bir durumda cache diskini kaynedersek veya arızalanırsa ne olur? Böyle bir durumda vSAN’da verileri kaybeder miyim? Önceki makalelerimi incelediyseniz orada da göreceksiniz. vSAN’da bir default policy vardır. Default storage policy RAID1 FTT = 1 ‘dir. Bu durum hatalı 1 cihazı tolere edeceğiniz anlamına gelir. Tabi siz burada storage policy’i RAID 0 olarak değiştirdiyseniz ozaman böyle hata tolere işlemi bulunmaz.

Disk grubu bir şekilde offline olduğunda cluster’da bulunan farklı vSAN node’larında bu verilerin ek bir kopyasının olduğunu unutmayın. Ek disk grubu oluşturmanız veya yapılandırmanız availability sağlamak için bir yol değildir. Availability sağlamak istiyorsanız SPBM yani Storage Policy Based Management kullanmanız gerekir. Storage Policy ile ilgili aşağıdaki yazmış olduğum makaleleri inceleyebilirsiniz.

VSAN – Storage Policy Data Locality

VSAN ve Storage Policies – Bölüm 1

VSAN ve Storage Policies – Bölüm 2

Arızalı olan disk değiştirilene kadar ve disk grubu rebuild edilene kadar 6 diskten oluşan disk grubundaki objeler (virtual machine ve dosyaları) offline’dir. Virtual machine’ler cluster’da bulunan ek kopyaları kullandığı için açık ve erişilebilir durumdadır.

Yukarıda bulunan 2 numaralı senaryoda ise, başarısızlık alanını azaltır çünkü artık arızalı bir cache diskiı 6 yerine yalnızca ilişkili 3 diske etki eder. Ayrıca bu etkilenen objelerin yeniden oluşturma süresini de azaltır. Yukarıda belirtmiş olduğum 1 numaralı senaryoda 1 disk grupta 1 cache disk 6 adet disk bulunuyordu. 2 numaralı senaryoda ise 2 farklı disk grup var 2 farklı cache disk bulunuyor.

Eğer vSAN arızalı bir diski tanımlarsa, onu degraded yani bozulmuş olarak olarak etiketleyecek ve bozulan nesneleri tekrar onarmaya başlayacaktır. Daha önce bir çok makalemde bunu belirttim ancak tekrar belirtmek istiyorum. vSAN’da rebuild şlemi için 60 dakika bekleyeceği düşünülüyor ancak eğer cihazları absent yani yok olarak işaretlenir ise bu altyapıda bir network kesintisi olduğu veya ESXi host’un yeniden başlatıldığını düşünerek yani geçici bir kesinti olduğunu düşünerek 60 dakika bekler. Eğer bir disk arızalanır veya hata olduğu işaretlenir ise vSAN, Storage Policy’de belirtmiş olduğunuz ayarları sağlamak için hemen yenide yapılandırmaya başlar.

3 Node vSAN Hata Senaryoları:

Her vSAN node’u üzerinde 2 kapasite diski olduğunu varsayalım. Bu şekilde 3 vSAN node’lu bir cluster’ımız var. FTT = 1 / FTM = RAID 1 etkileştirdiğimizi düşünelim. Yukarıdaki örneğe göre 2 node üzerine DATA ve yine tek node üzerinde witness bilgileri bulunmaktadır. FTT 1 olduğu için veriler ekstra farklı node üzerinde de tutulmaktadır. Böylece node’un biri down duruma geldiğinde cluster’da bulunan virtual machine’lerde bir kesinti olmayacaktır.

Bir node’da tamamen bir arıza meydana geldiğinde, yukarıdaki diyagramdaki gibi görünecektir. Elimizde verilerin hala iyi bir kopyasına sahip olduğumuzdan, virtual machine’lerin çalışmasına herhangi bir etkisi olmayacaktır. Bununla birlikte, vSAN’ın yedek kopyayı rebuild ve repair etmek için gerekli kaynaklara sahip olmayacağını belirtmek isterim. Çünkü 3 node’un bulunduğu bir ortamda 1 node down duruma geldiğinde verilerin bir kopyasını farklı node’lara dağıtılamaz. Bundan dolayı yedekliliğin tekrar sağlanması için down olan node’un tekrar kullanılabilir hale getirilmesi gerekir.

Peki arızalı diskler değiştirildiğinde veya tekrar sağlıklı duruma geldiğinde ne olur? Cluster’da yeterli alan oluşacağı için yedeklerin bir kopyası tekrar oluşacaktır.

4 Node vSAN Hata Senaryoları:

Şimdi 4 düğümlü bir kuruluma bakalım. 4 node’lu bir cluster’da tek bir düğüm hatasını gösterir. 4 node’lu bir cluster ile verilerin geri kalan düğümde hemen yeniden oluşturulabilmesi dışında, 3 node’lu bir kuruluma oldukça benzer görünüyor. Ancak 4 vSAN konfigurasyonunda RAID-1 ve RAID-5 konfigürasyonlarında FTT = 1 destekleyebilir. Bu konfigürasyon, RAID-1 kullanıldığında bir arıza durumunda vSAN’ın kendi kendini repair/rebuild etmesinede izin verir. Bu son noktayı detaylandıralım. Kendi kendini rebuild/repair ne demek istiyoruz? Bununla kastettiğimiz, bir vSAN host’u başarısız olursa ve cluster’da kullanılabilir boş kaynaklar varsa, vSAN sorunu otomatik olarak çözebilir. RAID-1 ve FTT = 1 sayesinde 3 bileşen vardır. Bunlar; verilerin ilk kopyası, verilerin ikinci kopyası ve witness. Bunların tümü ayrı vSAN node’ları üzerinde bulunur. vSAN node’unun biri arızalanırsa, cluster’da kaynağın olması durumunda bileşen yeniden oluşturulabilir ve VM bir kez daha arızaya karşı tam olarak korunur.

Biraz değiştirelim. Şimdi 4 node’lu bir vSAN cluster‘ımız var ancak 2 tane vSAN node’u aynı anda arızalanır ise ne olur? Normal şartlarda FTT = 1 olduğu için virtual machine’lere erişim sağlanamazdı değil mi? 4 node’lu bir vSAN altyapısında verilerin iki kopyası olduğu için çalışmaya devam edebilir. Devam edebilir diyorum çünkü FTT = 1 olduğu durumlarda 4 node’lu bir vSAN altyapısında 2 adet node’un aynı anda arızalanması durumunda her virtual machine düzgün bir şekilde çalışmayabilir. Bu arızalanan vSAN node’u üzerinde bulunan datalara göre değişkenlik gösterir. Çünkü data’nın bir kopyasının tutulmadığı node’un ve witness node’unun kaybedildiğini düşünürsek hiç bir sorun olmaz. Ama data’nın ve kopyasıın bulunduğu 2 node aynı anda kaybedilirse çeşitli sorunlar çıkabilir.

2 node veya 3 node’lu cluster’da yukarıda bahsetmiş olduğum işlemler mümkün değildir. Bir vSAN node’unun arızalanması durumunda, eksik bileşeni yeniden oluşturmak için (rebuild/repair) yer yoktur. Verilerin hem kopyalarını hem de verileri ve bir witness ile aynı node üzerine yerleştirmiyor. Bu çok mantıklı çünkü node’u kaybetmeniz durumunda büyük bir data kaybı yaşanır ve bundan dolayı virtual machine’e erişim sağlanamaz. Bu, VMware’in FTT = 1, RAID-1 için minimumda 4 node’lu bir cluster önermesinin nedenlerinden biridir. Ancak RAID-5 yapılandırmaları seçilirse, bu rebuild/repair davranışına 4 node’da sahip olamayacağınızı unutmayın. Bir RAID-5 stripe 4 bileşenden oluştuğundan, her bileşen farklı bir vSAN node’una yerleştirilir. RAID-5 ile kendi kendini rebuild/repair yapabilmesi için, cluster’da en az 5 vSAN node’a ihtiyacınız olacaktır.

Senaryo  vSAN Davranışı  Etki / Gözlemlenen VMware HA Davranışı  Cache diski hatası  Disk Grubu başarısız (failed) olarak işaretlenir ve üzerinde bulunan tüm bileşenler başka bir Disk Grubunda yeniden oluşturulur. VM çalışmaya devam edecektir. Kapasite disk hatası (Data Deduplication ve Compression AÇIK)  Disk Grubu başarısız (failed) olarak işaretlenir ve üzerinde bulunan tüm bileşenler başka bir Disk Grubunda yeniden oluşturulur. VM çalışmaya devam edecek. Kapasite disk hatası (Data Deduplication ve Compression KAPALI)  Başarısız olarak işaretlenen disk ve içindeki tüm bileşenler başka bir diskte yeniden oluşturulur. VM çalışmaya devam edecek. Disk Grubu hatası / offline  Disk Grubunda bulunan tüm bileşenler başka bir Disk Grubunda yeniden oluşturulacaktır. VM çalışmaya devam edecek. RAID / HBA kartı hatası  HBA / RAID kartı tarafından desteklenen tüm Disk Grupları yok olarak işaretlenecek ve mevcut tüm bileşenler diğer Disk Gruplarında yeniden oluşturulacaktır. VM çalışmaya devam edecek. ESXi host hatası ESXi host üzerindeki bileşen, vSAN tarafından absent (yok) olarak işaretlenecektir – ESXi host geri gelmezse, bileşen yeniden oluşturma 60 dakika sonra başlatılacaktır. Rebuild/Repair işlemi. VM, başka bir ESXi host üzerindeyse çalışmaya devam edecektir. Virtual machine arızalanan ESXi host’da çalışıyorsa, Virtual machine’in vSphere HA tarafından yeniden başlatması gerçekleşir. ESXi host’un izolasyonu (network erişimini kaybetmesi vs.)  ESXi host’da bulunan bileşenler, vSAN tarafından absent (yok) olarak işaretlenecektir. ESXi host yeniden online olmaz ise, bileşen rebuild/repair işlemleri 60 dakika sonra başlatılır. Virtual machine, başka bir ESXi host’da çalışmaya devam edecektir. Virtual machine, arıza ile aynı ana bilgisayarda çalışıyorsa, Virtual machine’in vSphere HA tarafından yeniden başlatması gerçekleşir.

  Son olarak, altyapınızda vSAN kullanıyorsanız gerçekten verileriniz emin ellerde diyebiliriz:) Elbette burada hata senaryolarını arttırabilirsiniz. Ancak karşılaştırmaları yaparken belirli mantık çerçevesinde yapmak lazım. Her türlü hata senaryosunu düşünecek olursanız fiziksel bir storage’ida down etmek mümkündür. Bundan dolayı en basit çözümler ile data güvenliğini nasıl sağlıyoruz bunu düşünmemiz gerekiyor. vSAN bize bu konuda oldukça fazla avantaj sağlıyor. Hata senaryoları ile ilgili buradaki makaleyide incelemenizi tavsiye ederim. Daha önce yazmış olduğum makaleleri okumanızı tavsiye ediyorum. Çünkü burada bahsetmiş olduğum bilgilerin bir kısmını aslında daha önce farklı makalelerde yazmıştı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 https://www.tayfundeger.com/sap-hana-ve-vmware.html

SAP HANA ve VMware

Merhaba,

SAP HANA ve VMware isimli bu yazımda sizlere VMware vSphere üzerinde bulunduracağınız SAP HANA virtual machine’lerinin özellikleri ve önerilen konfigurasyonları hakkında detaylı bilgiler vereceğim.

Daha önce SAP ile ilgili aşağıdaki gibi bir makale yazmıştım.

VMware Best Practices for SAP

SAP kullanıcıları, VMware vSphere üzerinde sanallaştırılmış SAP HANA platformunu çalıştırarak önemli avantajlar sağlar. Öncelikle Sanallaştırma mimarisinde SAP HANA kullandığınızda eğer ortamınızda bir cluster var ise fiziksel donanımda bir sorun yaşanması durumunda çalışan virtual machine’i farklı bir host’a migrate edebilir veya fiziksel donanımın ansızın kapanması durumunda virtual machine’in farklı bir host üzerinde vSphere HA sayesinde açılmasını sağlayabilirsiniz. Elbette sanallaştırma mimarilerinin operasyonel anlamda ciddi kazanımları bulunmaktadır. SAP HANA sistemlerini VMware sanallaştırma ortamlarında sorunsuz kullanabileceğinizi belirtmek isterim.

SAP HANA ve VMware

SAP HANA sunucularını VMware ortamlarında çalıştırmanız durumunda aşağıdaki yeteneklerden faydalanacağınızı belirtmek isterim.

NSX veya DRS sayesinde artırılmış güvenlik ve SLA oranları.

VMware vSphere vMotion sayesinde çalışan SAP HANA sunucularının farklı bir host’a power on bir şekilde migration işlemi.

vSphere HA sayesinde SAP HANA virtual machine’inin çalıştığı ESXi host’un down olması durumunda virtual machine’ler otomatik olarak cluster’da bulunan farklı ESXİ host’lar üzerinde power on olabilecektir. vSphere HA ile ilgili aşağıdaki makalelerimi inceleyebilirsiniz.

Objective 2.2 – Describe HA solutions for vSphere

Testing vSphere HA

SAP HANA’nın çalışacağı VMware ortam ortamlarında aşağıda belirteceğim işlemlere dikkat etmeniz gerekiyor. vSphere 7.0 U1 geçtiğimiz günlerde release oldu ve ben bu makalede vSphere 7.0 U1 ile ilgilide ekstra bilgiler vereceğim.

vSphere 7.0 U1 ile birlikte bir SAP HANA virtual machine’i üzerinde maksimum konfigurasyonlarda bazı değişiklikler oldu.

SAP HANA ve VMware

vSphere 7.0 U1 ile birlikte SAP HANA çalıştırılacak virtual machine’lere 6 TB memory verebilirsiniz. Ancak bu memory miktarını şuan için Skylake ve Cascade lake tabanlı işlemcileri kullanıyorsanız verebilirsiniz. SAP HANA için virtual machine üzerinde minimum 128GB memory olması gerekmektedir. Tabi bu sizin SAP HANA üzerinde çalıştıracağınız iş yüküne göre değişkenlik gösterir.

Bir SAP HANA VM yapılandırması, maksimum 256 vCPU ile yapılandırılabilir. Haswell tabanlı sistemlerde maksimum 144 vCPU, Broadwell tabanlı sistemler maksimum 192 vCPU ve Skylake ve Cascade Lake tabanlı sistemlerde maksimum 224 vCPU yapılandırılabilir. Dolayısıyla bu, CPU kaynakları (SAPS kapasitesi) SAP HANA VM’nin sınırlayıcı faktörüdür. SAP, üretim için bir SAP HANA sistemi için minimum 8 pCPU çekirdeği talep eder. Bugün itibariyle Haswell (18 çekirdekli CPU) veya daha sonraki CPU nesli (Yarım Soket VM) ile CPU soketi başına maksimum 2 VM’ye izin verilmektedir.

Daha önceki makalelerimden hatırlayabilirsiniz. Persistent memory denilen bir kavram ortaya çıktı. Persistent Memory sayesinde çok yüksek performans alabilirsiniz. Persistent memory ile ilgili makalemi aşağıdaki linkten inceleyebilirsiniz.

vSphere 6.7 – Persistent Memory

vSphere 6.7 EP14 ve vSphere 7.0 U1 ile birlikte SAP HANA sunucularında PMEM yani Persistent Memory kullanabilirsiniz. Ancak bunu kullandığınızda bazı kısıtlamalar karşımıza çıkıyor. VMware, vSphere 6.7 ve 7.0 ile Intel Optane PMem’i destekler. VMware ve Intel, SAP HANA’nın Optane PMem özellikli VM’lerle çalışmasını sağlamak için SAP ile birlikte çalıştı. vSphere 6.7’de (6.7 EP 14 sürümünden itibaren) 6 TB’a kadar (DRAM + Optane PMem) SAP HANA VM’lerin ve ayrıca vSphere 7.0 U1 sürümünden itibaren artık desteklenmektedir. Ayrıntılar için SAP Note 2913410‘a bakabilirsiniz. VMware, müşterilerin SAP’den özel danışmanlık almasını şiddetle tavsiye ediyor. Eğer Persistent Memory kullanacak iseniz bazı kısıtlamalara dikkat etmeniz gerekiyor.

SAP HANA ile birlikte Optane PMem özelliğini kullanacaksanız vSphere HA support edilmiyor. vSphere HA ihtiyaçları için SAP HANA System Replication gibi 3 party bir ürünü kullanmanız gerekecektir. Tabiki şunu  söyleyebilirsiniz. SAP HANA çözümlerinde zaten yüksek memory kullanılıyor ve vSphere HA ‘in kullanılması için cluster’da yeterli kaynağınızda olmayabilir veya olası bir downtime durumunda SAP HANA virtual machine’i farklı host’da kaynak yetersizliğinden dolayı açılmayabilir. Özet ile SAP HANA sunucularının bulunduğu cluster’da eğer vSphere HA kullanılacak ise kaynak planlaması iyi bir şekilde yapılmalıdır.

SAP HANA ve VMware

Yukarıdaki görseli incelediğinizde SRM konusu dikkatinizi çekebilir. VMware SRM, disaster recovery çözümüdür. vSphere Replication sayesinde virtual machine’i farklı bir lokasyona replike edebilirsiniz. vSphere Replication kullanıyorsanız minimum 5 dakikalık bir RPO ile bu işlemi gerçekleştirebilirsiniz. SAP HANA virtual machine’leri için replikasyonu kullanabilirsiniz ancak RPO süresi 5 dakika olduğu için yani replike edilen data 5 dakika geç geleceği için SAP HANA database ‘inde sorunlar ile karşılaşabilirsiniz. Bundan dolayı VMware SRM ve vSphere Replication’in kullanılması önerilmez. Aynı durum FT içinde geçerlidir.

vSphere vMotion özelliği sayesinde bir virtual machine’i power on bir şekilde farklı bir ESXi host’a migrate edebiliyoruz. vSphere 7 ile birlikte vMotion özelliğinde de bazı değişiklikler yapıldı. vSphere 7 üzerinde çalışan SAP HANA virtual machine’lerinde vMotion işlemi başlatıldığında vSphere 6.7’ye göre 2.5 kat daha hızlı sonuç alındığı belirtiliyor. vSphere 7 ile birlikte gelen vMotion yenilikleri ile ilgili ayrıca bir makale yazacağım.

SAP HANA kullanıyorsanız aşağıda belirteceğim Best Practices’lere dikkat etmeniz gerekiyor.

SAP HANA sunucularında Memory rezervasyonu yapılmalıdır. Sunucu üzerinde memory miktarı kadar rezervasyon yapılmalıdır.

Paravirtual SCSI Controller kullanılmalıdır.

VMxnet3 network kartı kullanılmalıdır.

ESXi host’un çalıştığı fiziksel sunucuda HT aktif durumda olmalıdır.

vMotion, management, backup ve replikasyon için kullanılan network’ler dedike olmalıdır. Yani SAP HANA virtual machine’i ile bu belirtmiş olduğum VMkernel network’leri aynı uplink’i kullanmamalıdır.

Yoğun kullanım olduğu zamanlarda vMotion ve Snapshot almayın.

CPU yapılandırması yaparken CPU Ready Time’a dikkat edin.

Aşağıdaki SAP HANA ve VMware parametrelerini uygulayın.

transparent_hugepage=never numa_balancing=disabled vmw_pvscsi.cmd_per_lun=254 vmw_pvscsi.ring_pages=32

Son olarak; SAP HANA yüksek gereksinimlerinden dolayı sanallaştırma ortamlarında size bazı zorluklar çıkarabilir. Özellikle vMotion ve Snapshot gibi operasyonlarda eğer dikkatli olmaz iseniz başınıza dertler açabilir. SAP HANA virtual machine’lerinin memory ve disk boyutları yüksek olduğu için uyarıyorum aslında. Çünkü bir virtual machine’i vMotion ile farklı bir ESXi host’a migrate etmek istediğinizde virtual machine’in memory datası taşınır. Virtual machine’in memory’si ne kadar büyük ise migration işlemi o kadar uzun sürecektir. vMotion tamamlandığında ise virtual machine üzerinde anlık ping kayıpları görebilirsiniz. Aynı durum snapshot içinde geçerlidir. Disk ve Memory ne kadar yüksek ise snapshot işlemi o kadar uzun sürecek ve performans sorunu yaşamanızda kaçınılmaz olacaktır. Bundan dolayı SAP HANA gibi ürünlerde kesinlikle snapshot ve vMotion işlemleri mümkün olduğunca gerçekleştirmeyin.

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.