Merhaba, bu yazımda sizlere Failover Cluster Kesintisiz Sistem Güvenilirliği ve En İyi Uygulamalar konusundan bahsedeceğim. Sizler için bir Failover Cluster kurulumu yaparken nelere dikkat edilmeli? Failover Cluster konfigürasyonu nasıl olmalı? Ve daha fazlasını içeren güzel bir rehber hazırladım. Bu makalede yalnızca sanallaştırma ortamına kurulmuş Windows sunucu üzerinde Failover ön hazırlık ve gereksinimlerden bahsediyorum. Tüm makaleyi toplam 4 ayrı yazıda detaylı bir şekilde anlatacağım.
Microsoft tarafında incelemek isterseniz önemli linkleri de aşağıya bırakıyorum.
Failover clustering hardware requirements and storage options
Failover Clustering in Windows Server and Azure Local
Windows Server Failover Clustering, sunucu hizmetlerinin yüksek erişilebilirlik ile çalışmasını sağlar ve bir sunucu arızalandığında diğerine devrederek kesintiyi en aza indirir. Sanallaştırma ortamında (ör. Hyper-V veya VMware üzerinde çalışan Windows Server sanal makineleri) bir failover cluster kurarken, hem fiziksel/sanal donanım kaynakları hem de yazılım yapılandırmaları açısından çeşitli en iyi uygulamaları takip etmek önemlidir.
Ön Hazırlık ve Gereksinimler
Windows Server Sürümü ve Lisanslama
Failover Cluster kurulacak tüm sunucular aynı Windows Server sürümüne ve tercihen aynı versiyona (Standard veya Datacenter) sahip olmalıdır. Windows Server Standard ve Datacenter sürümleri failover clustering özelliğini destekler ve teorik olarak bir kümede 64 düğüme kadar çıkılabilir.
Tüm düğümlerin aynı işletim sistemi versiyonunda ve benzer yama seviyesinde olması, uyumluluk açısından kritik önemdedir
Lisanslama tarafında, Datacenter Edition genellikle sanallaştırma yoğun ortamlarda tercih edilir. Datacenter lisansı, tek bir fiziksel ana sunucu için sınırsız sayıda Windows Server sanal makinesini lisanslama hakkı verdiğinden, özellikle Hyper-V rolüyle birden fazla VM çalıştıran cluster ortamlarında maliyet avantajı sağlar
Standard Edition ise sınırlı sayıda sanal makine (genellikle 2 VM) lisansını kapsar ve daha küçük ölçekli kümeler için yeterli olabilir. Sonuç olarak, cluster düğümlerinin lisanslarının geçerli ve ortama uygun olduğundan emin olunmalıdır. (Not: Windows Server failover cluster özelliği, Foundation veya Essentials gibi alt sürümlerde mevcut değildir; Standard ya da Datacenter gerekir.)
Donanım ve Kaynak Gereksinimleri
Sunucu Donanımı: Cluster’ı oluşturan tüm sunucuların benzer veya aynı donanım konfigürasyonuna sahip olması önerilir. Bu, işlemci mimarisi, bellek kapasitesi, depolama türü ve ağ kartları gibi bileşenlerin uyumlu olmasını sağlar.
Örneğin tüm düğümlerde aynı model CPU ya da benzer hızda CPU, aynı miktarda RAM ve mümkünse aynı marka/model sürücüler kullanılması olası performans ve uyumluluk sorunlarını azaltır. Farklı donanım da teknik olarak çalışabilir ancak tutarlılık, cluster performansı ve sorunsuz failover için kritik bir faktördür. Ayrıca Windows Server Failover Clustering, Microsoft tarafından tam destek için Windows Server sertifikalı donanım kullanılmasını şart koşar. Yani kullanılan sunucuların ve bileşenlerin Microsoft’un onayladığı uyumluluk testlerinden geçmiş olması (Windows Server Catalog listesinde yer alması) önerilir
CPU, Bellek ve VM Kaynakları
Her bir düğüm, cluster üzerinde çalışacak iş yüklerini (ör. sanal makineler, uygulama servisleri vb.) kaldırabilecek yeterli CPU çekirdek sayısına ve RAM kapasitesine sahip olmalıdır. Cluster yapısı, bir düğüm arızalandığında üzerindeki tüm yükün diğer düğümlere devredileceği şekilde planlanmalıdır. Örneğin iki düğümlü bir Hyper-V cluster’da, her bir host normalde %50 kaynak kullanacak şekilde boyutlandırılmalıdır ki bir host düştüğünde diğer host tüm sanal makineleri çalıştırmaya devam edebilsin. Benzer şekilde üç düğümlü bir cluster’da N+1 yedeklilik planlanarak herhangi bir düğüm kaybında kalanların işi üstlenebileceği hesaplanır. Bellek tarafında, cluster servisinin kendisi çok büyük bir yük getirmese de (typik olarak hafiftir), barındırılacak sanal makinelerin toplam bellek ihtiyacı ve olası büyüme payı göz önüne alınmalıdır.
Ağ Kartları
Her cluster düğümü üzerinde birden fazla ağ adaptörü bulunması şiddetle tavsiye edilir. Tek bir NIC üzerinden hem tüm cluster iletişimini hem istemci trafiğini yürütmek, o NIC arızalanırsa cluster’ın bölünmesine veya hizmet kesintisine yol açar. Bu nedenle en az iki fiziksel NIC kullanılmalıdır. Ağ altyapısında tekil arıza noktalarını ortadan kaldırmak önemlidir; cluster düğümleri birden çok ve bağımsız ağ ile birbirine bağlanmalıdır veya alternatif olarak NIC Teaming gibi yöntemlerle birden fazla fiziksel bağlantı tek bir mantıksal arayüzde birleştirilmelidir
Örneğin, her sunucuda iki ethernet portu varsa, bunların biri bir switch’e diğeri ikinci bir switch’e bağlanarak veya ikisi birden takım yapılarak bir NIC arızasına ya da switch arızasına karşı yedeklilik sağlanır. (NIC Teaming konusuna, avantajlarına ve yapılandırma ipuçlarına Bölüm 3’de ayrıca değinilecektir.) Yüksek performanslı gereksinimler için 10 Gbps veya üzeri hızlı ağ kartları (özellikle sanal makine canlı taşıma – Live Migration, depolama replikasyonu veya S2D için) tercih edilmelidir.
Active Directory, DNS ve IP Yapılandırması
Failover cluster kurulumundan önce, Active Directory (AD) ortamının hazır olması gerekir. Tüm cluster düğümleri aynı Active Directory etki alanına üye olmalıdır ve etki alanı denetleyicisiyle güvenilir bir bağlantıya sahip olmalıdır.
Genelde cluster düğümleri için ayrı bir OU (Organizational Unit) oluşturulup bu sunucu hesaplarının oraya taşınması önerilir; bu sayede cluster düğümlerine uygulanacak grup politikaları diğer sunuculardan izole edilebilir ve cluster ile ilişkili nesnelerin (ör. cluster adı) yanlışlıkla silinmesi önlenebilir.
Cluster oluşturulurken, sihirbaz AD içinde “Cluster Name Object (CNO)” denen bir bilgisayar nesnesi oluşturur ve bu nesne DNS’de cluster’ın adıyla ilişkilendirilir. AD izinleri: Cluster oluşturacak hesabın, AD içinde yeni bilgisayar nesnesi oluşturma yetkisi olmalıdır (ya da alternatif olarak bir AD yöneticisi önceden ilgili adı oluşturup gerekli izinleri atamalıdır). Bu yetki yoksa cluster adı kayıt edilemez ve cluster kaynakları çevrimiçi olamaz.
DNS Yapılandırması
Cluster adı için DNS’de bir A kaydı oluşturulacak (genelde cluster oluşturma sırasında otomatik yapılır). Bu nedenle DNS sunucusunun, cluster düğümlerinin IP adreslerini ve oluşturulacak cluster IP adresini barındıran ağı yönetiyor olması gerekir. DNS kayıt güncellemelerinin dinamik olarak başarısız olması durumunda (örneğin güvenlik nedeniyle dinamik güncelleme kapalıysa), cluster adı kayıt sorunu yaşanabilir. Böyle bir durumda cluster adını ve IP’sini DNS’e elle eklemek gerekebilir. Ayrıca cluster içindeki her düğümün kendi ana adı (hostname) ve IP’si de DNS’de doğru şekilde çözülmelidir. Düğümler arasında ad çözümleme sorunu (DNS yanlış veya eksik kayıtlar) cluster kurulumunu ve kararlılığını olumsuz etkiler.
IP Adres Planlaması
Cluster için her bir network (bkz. ağ bölümü) kapsamında uygun IP adresleri planlanmalıdır. Genellikle, cluster’ın kendisi için (CNO’nun kullanacağı) bir sanal IP adresi tahsis edilir. Örneğin düğümler 10.0.1.10 ve 10.0.1.11 ise, cluster IP’si 10.0.1.12 olabilir ve bu IP cluster adıyla DNS’ye kaydolur. Bu IP adresi, cluster üzerindeki istemci erişimli hizmetler için birincil erişim noktası olur. IP yapılandırmasında statik IP kullanılması çoğu zaman tercih edilir, zira cluster düğümlerinin ve cluster IP’nin değişken olmaması yüksek erişilebilirlik senaryosunda daha öngörülebilir bir davranış sağlar (DHCP ile de cluster IP alınabilir ancak DHCP kesintileri bu IP’nin kaybına yol açmamalıdır).
Subnet/Ağ Ayarları
Tüm cluster düğümleri aynı IP alt ağındaysa, cluster tek bir subnet üzerinde çalışacaktır. Eğer coğrafi dağıtık bir cluster (stretch cluster) söz konusuysa ve düğümler farklı subnet’lerde ise, multi-subnet cluster konfigürasyon detaylarına (ör. Orchestrator “Site Awareness”, ağ gecikme parametrelerine) dikkat edilmelidir. Bu rehberde ağırlıklı olarak aynı lokal ağ içindeki cluster ele alınmaktadır.
Etki Alanı Denetleyicisi (DC) Konumu
Mümkünse cluster düğümleri etki alanı denetleyicisi rolünü üstlenmemelidir. Bir DC’nin cluster üyesi olması teknik olarak mümkün olsa da tavsiye edilmez; çünkü cluster, AD’ye güvenerek çalışır ve eğer cluster düğümü olan DC kapanırsa bazen karmaşık başlatma sorunları ortaya çıkabilir. Microsoft, bir failover cluster içindeki sunucuların ayrı bir DC tarafından yönetilmesini önerir
Bu nedenle, cluster’ı kurmadan önce ortamınızda en az bir harici (cluster dışında) DC ve DNS sunucusunun çalıştığından emin olun.
Depolama Gereksinimleri (Paylaşımlı Diskler ve Storage Spaces Direct)
Bir failover cluster kurmak için ortak bir depolama altyapısı şarttır. Tüm düğümlerin erişebileceği paylaşımlı disk(ler) olmadan, durum bilgisi gerektiren cluster rolleri çalıştırılamaz. Bu gereksinim, Windows Server 2012 ve sonrasında tanıtılan Storage Spaces Direct (S2D) teknolojisiyle biraz esnekleşmiştir; artık geleneksel bir SAN kullanmadan, cluster düğümleri üzerindeki yerel diskleri birleştirerek yazılım tanımlı bir depolama havuzu oluşturmak da mümkündür.
Paylaşımlı Disk Tabanlı Depolama
Bu senaryoda bir SAN (Storage Area Network) veya NAS üzerinde LUN’lar tanımlanarak tüm cluster düğümlerine sunulur. Paylaşımlı depolama olarak iSCSI, Fiber Channel, SAS veya SMB 3.0 file share kullanılabilir. Örneğin Hyper-V sanal makinelerini barındıran bir cluster, sanal disklerin tutulduğu LUN’a her iki düğümün de erişebilmesi için iSCSI ya da FC üzerinden bağlanır. Microsoft, Hyper-V cluster senaryolarında doğrudan SMB 3.0 paylaşımları da desteklemektedir (Scale-out File Server üzerinden)
Paylaşımlı disk kullanan bir cluster’da, bu diskin SCSI-3 Persistent Reservation (SCSI-3 PR) desteğinin olması gerekir; cluster, disk erişim koordinasyonunu PR ile yönetir.
Storage Spaces Direct (S2D) ile Yazılım Tanımlı Depolama
Windows Server 2016 ve üzeri Datacenter sürümlerinde bulunan S2D, her düğümdeki yerel diskleri (SSD/HDD/NVMe) birleştirerek cluster içinde dağıtık bir depolama havuzu oluşturur. Bu yapı, geleneksel bir paylaşımlı disk gereksinimini ortadan kaldırır – tüm diskler düğümlerin içindedir, veri cluster içinde yansıtılır veya parçalanır. S2D kullanımı yüksek hızlı ağ (en az 10 GbE, tercihen RDMA desteği olan NIC’ler) ve mümkünse en az 3-4 düğüm ile önerilir (2 düğüm S2D mümkündür ancak sınırlıdır). S2D etkin bir cluster’da, cluster otomatik olarak Cluster Shared Volume (CSV) yapılandırmasını ve gerekli quorum ayarlarını yapar. (S2D detayları bu rehberin kapsamı dışında derin bir konu olduğundan, burada sadece gereksinimleri ve genel tavsiyeleri belirtiyoruz.)
Disk Yapılandırması ve Dosya Sistemi
Cluster, paylaşımlı depolamada temel diskleri (basic disk) destekler; dinamik diskler cluster ile uyumlu değildir ve kullanılmamalıdır
Paylaşımlı LUN’lar, her düğüm tarafından aynı şekilde görülecek şekilde düzenlenmelidir (aynı LUN ID veya aynı iSCSI hedefi tanımları ile). Bölümlendirme stili olarak GPT kullanılması, özellikle 2 TB üzeri disk boyutları için gereklidir (MBR diskler 2 TB ile sınırlı olduğundan). Dosya sistemi olarak NTFS standarttır ve önerilir; failover cluster içindeki disk tanık (quorum diski) NTFS veya ReFS formatlı olabilirken, Cluster Shared Volume (CSV) olarak kullanılacak disklerin NTFS ile formatlanması zorunludur
Özetle, cluster kullanımı için paylaşımlı diskleri NTFS ile biçimlendirip çevrimiçi (online) duruma getirdikten sonra cluster’a eklemek en iyi uygulamadır.
Depolama Ağları ve MPIO
Eğer cluster düğümleri paylaşımlı disk bağlantısını iSCSI üzerinden yapıyorsa, her düğümde depolama trafiğine ayrılmış ayrı bir (veya birden fazla) ağ adaptörü bulunmalıdır. İSCSI için kullanılan ağ arayüzü sadece depolama amacıyla kullanılmalı, normal istemci veya cluster iletişim trafiğini taşıyan NIC’lerle karıştırılmamalıdır
Bu iSCSI ağının da yedekliliği önemlidir: Birden fazla yol için Microsoft MPIO (Multipath I/O) yazılımı yapılandırılarak bir disk LUN’ına birden fazla ağ yolundan erişim sağlanabilir. Örneğin, iki ayrı switch üzerinden iSCSI hedefe giden iki NIC varsa, MPIO ile bir NIC arızalansa bile depolama bağlantısı kesilmez. Alternatif olarak, iSCSI ağında NIC Teaming de kullanılabilir ancak MPIO, depolama protokolü seviyesinde daha verimli bir yol yedekliliği sunar. Depolama ağlarında gecikmeyi düşürmek için jumbo frame (MTU 9000) desteği etkinleştirilebilir.
Depolama testi
Cluster kurulumu öncesi, tüm düğümlerin paylaşımlı depolamayı görebildiğini ve okuma/yazma yapabildiğini doğrulamak gerekir. Kurulum sihirbazındaki Validate Configuration sihirbazı, “Depolama” testleri ile LUN’ların erişilebilirliğini ve persistent reservation desteğini kontrol edecektir (bu testlerde hata alınmaması kritik önem taşımaktadır.
Quorum (Eşitlik) Tanığı için Depolama
İki veya daha fazla düğümlü cluster’larda quorum hesabı için bazen paylaşımlı bir disk tanık (disk witness) kullanılır. Eğer cluster’ınızda bir Disk Witness (Disk Tanığı) kullanmayı planlıyorsanız, çok büyük bir depolama alanına ihtiyaç yoktur – küçük bir disk bölümü (ör. 1 GB bile yeterli) bu amaçla ayrılabilir. Disk witness, cluster yapılandırma veritabanının bir kopyasını tutar ve oylamada ekstra bir oy hakkı sağlar (Quorum ayarları Bölüm 2’de ayrıntılı incelenecektir). İki düğümlü bir cluster’da genellikle disk tanık veya paylaşımlı bir Dosya Paylaşımı Tanığı (File Share Witness) kullanılması gerektiğini unutmayın, aksi halde tek bir düğüm arızasında quorum kaybı yaşanabilir.
Bu yazımda sizler için Failover Cluster için gerekli ön hazırlıkları anlattım. Bölüm 2 yazımda görüşmek üzere. Faydalı olması dileğiyle.
