Windows Server

Microsoft Failover Cluster Disk Yönetimi Persistent Reservation

Microsoft Failover Cluster’ın olmazsa olmaz üç temel şartı vardır. Bunlar; Shared (paylaşılmış) Disk, Quorum ve networktür. Bu makalemizde Failover Cluster servisinin Cluster’a üye node’lar arasında Shared disk yönetiminin nasıl yapıldığı (Persistent Reservation) ve olası disk rezervasyon sorunun çözümü anlatılacaktır.

Hyper-V ve Scale-Out File Server hariç tüm Microsoft Failover Cluster çözümleri aktif pasif çalışan bir sistemdir. En temel özelliği Cluster’a dâhil her bir kaynağın (Resource) sadece tek bir sahibinin olmasıdır ki o da aktif node’tur. Daha detaylı bilgiye aşağıdaki linkten erişip izleyebilirsiniz.

 http://tv.cozumpark.com/video/646/Microsoft-Failover-Cluster-Nedir

8 yıllık tecrübem de karşılaştığım problemlerin %90’ı Disk erişim problemi olarak sonuçlanmıştır. Geri kalan %10’da ise düzenli OS ve Donanım güncellemesi yapmamanın ceremesi olarak bilinen bir bug’a denk gelme. Bu makaleyi hazırlamamın en temel nedeni, yaşamış olduğum bu disk erişim problemlerindeki tecrübeleri siz Çözümpark ailesi ile paylaşıp olası bir problemde ne yapılacağını bilmenizi sağlamaktır.

Konumuza geçmeden önce Failover Cluster servisinin en temel ihtiyacı Shared (Paylaşımlı) Diski tanıyarak başlayalım. Shared Disk, özet hali ile Cluster’a üye tüm Node’ların aynı diski görmesi/erişmesi fakat sadece aktif Node’un (Hyper-V ve Scale-Out File Server hariç) yazabilmesini ifade etmektedir. Bu yapıda Cluster’ın çalışma tipine Shared Nothing modeli denir.

clip_image002

Aynı anda birden fazla işletim sisteminin bir diske bu şekildeki erişimi corruption (bozulma) neden olur. Bütün işletim sistemlerin dosya sistemi yönetim sürücüleri (ntfs.sys) bir diske sadece kendileri eriştikleri bir mantıkla tasarlanır. Ondan birden fazla işletim sistemi ve böylece birden fazla dosya sistemi yönetim sürücüsü bir anda aynı disk üzerinde çalışırlarsa corruption oluşma olasılığı çok yüksektir. Bu sorunun çözümü için SCSI standarttı geliştirip tüm vendor’lar tarafından uygulanması beklenmiştir.

Her diskin storage üzerinde bir Rezervasyon tablosu bulunmaktadır. Ayrıca her sunucu için storage seviyesinde ID (özel bir unic key) üretilir. Storage üzerinde oluşturulan disk Cluster’a üye tüm Node’lara map’lenir. (Bu süreç storage firmasına göre farklılık gösterdiğinden burada bahsedilmeyecektir.) Bu tabloda erişim yetkisi olan adresler (WWN, iQN v.b) ve asıl sahibinin adresi bulunur. Microsoft Failover Cluster tüm üye node’ların key’lerini bilir.

clip_image004

Uygulama (örneğin SQL) veriyi oluşturur. Cluster servisine (Clusdisk) bu verinin yazılacağı diskin harfi ile bildirerek yazdırma talebi yapar. Cluster verinin diskine yazılması için işletim sistemine ait dosya sistemi yönetim sürücüsüne (ntfs.sys) bildirir. NTFS.sys diskin ID’si ile disk.sys’ye atar.

clip_image006

Eğer sunucu üzerinden birden fazla HBA veya Network kartı varsa ve MPIO servisi kurulu ise MPIO katmanına gönderir. MPIO veriyi parçalayarak DSM katmanına gönderir. Eğer MPIO kullanılmıyorsa direk storage’e gönderir. İşletim Sisteminden çıkış noktasında (HBA portu veya Network portu) 8 bit’lik alan eklenerek buraya port bilgileri girilir.

DSM (Device Specific Module) katmanının en önemli özelliği ntfs.sys komutlarını storage’in anladığı komutlar haline çevirerek veya ekleyerek gönderir. Bu katman genellikle storage için SCSI komutları yeterli gelmediğinde storage üreticisinin yazılımı tarafından ntfs.sys komutları storage diline çevirerek veya ek komutları eklenerek gönderir.

Storage gelen veri ile birlikte hangi sistemin diskine yazacağını bilir. Rezervasyon tablosuna gelen sunucu key’ini girip veriyi diske yazar.

Kontrollü Failover Süreci:

Failover Cluster Manager üzerinden veya komut ile cluster yapılmış Role move (Failover, servisin diğer node’a taşınması) talebi yapıldığında. Servisin yeni işlem alması durdurulur. Cluster policy’sinde belirtilen değer süresince üzerindeki işleri bitirmeye çalışır. Eğer belirlenen sürede kuyruktaki işler biterse Cluster SCSI-3 komutu ile diskin rezervasyonunun silinmesi için storage’e talepte bulunur. Storage tarafından Persistent Reservation kaldırıldıktan sonra Failover işlemi başlar.

Eğer Cluster kurallarında belirtilen sürede kuyruk temizlenmezse Failover süreci fail (hata) verir. Eğer disk rezervasyonu kaldırılamazsa Failover süreci fail (servis offline’a düşer) verir.

Storage PR kaydını kaldırıp Failover süreci ilerlemeye başladığında servisi üzerine alan sunucu disk için PR talebinde bulunur. Rezervasyon tablosu boş olduğundan servisi üzerine alan sunucunun yaptığı disk erişim talebi kabul edilip tabloya işlenir.

Disk Erişim bazlı Failover Durumları:

1) Port erişiminin kaybedilmesi: Aktif Node’un birden fazla port ile Multi Path (MPIO) kurulu olarak storage’e veri gönderiliyorken Eğer portlardan biri arızalanırsa sistem kesintiye uğramadan diğer port üzerinden veri akışı sağlanacağından iş sürekliliği sağlanmış olur.

Tüm Cluster Node’ları default olarak her 5 saniye de bir birbirini Heartbeats (private) network üzerinden sağlık kontrolünü yapar. Eğer Aktif Node’un tüm portları arızalanırsa veya bir şekilde disk erişimini kaybederse otomatik Failover sürecini kendisi başlatır.

clip_image008

2) Aktif Node’un Disk erişimini kaybetmesi: Default olarak aktif node her 3 saniyede bir pasif node ise her 7 saniyede bir storage’e Disk rezervasyon tablosunda SCSI-3 Persistent Reservation (PR) komutu ile var olan kaydın silinip (Clear) kendini kaydettirir. Bu işleme Arbitration işlemi denir. Eğer storage SCSI-2 destekliyorsa bu işleme Bus Reset e eş gelir.

Eğer pasif node iki kere yapılan kontrolde kendisini görürse ya storage ya da sunucu tarafta sıkıntı olduğunu düşünür. Aşağıda linkini verdiğim adreste Split-Brain senaryosundan detaylı olarak bahsettiğimizden burada fazla detaya girmeyeceğim.

http://www.cozumpark.com/blogs/windows_server/archive/2014/03/02/microsoft-cluster-mimarisinde-quorum-yapilandirmasi-ve-split-brain-senaryosu.aspx

Eğer sunucu tarafta sıkıntı olduğunu teyit ederse diskin Failover sürecini başlatır. Failover sürecinin başlayabilmesi için Cluster servisi diskin rezervasyon tablosunun silinmesi için SCSI-3 komutları ile silme talebinde bulunur. Talep storage’e ulaştıktan sonra storage diskin rezervasyon tablosunu temizler. En basitçe ifade etmek gerekirse, Windows cluster servisini Persistent Reservation talepleri yapan bir istemci olarak düşünebilirsiniz. Persistent Reservation taleplerini istemci olarak Windows yapar, fakat işlemi yapan, kaydını tablosunu tutan ve ne olacağına nihai olarak karar veren arkadaki Storage yazılımı ve donanımı bileşenleridir. Bu sayede başka sunucuların o diske erişmelerini engeller.

clip_image010

Cluster Disk Rezervasyon Kaldırma Hataları

Cluster’da diskleriniz online yapılmaya çalışıldığında aşağıda detayları sunulan Event ID 1069 hatası alıp hemen failed’a düşüyorsa Diskinizde başka bir node’dan rezervasyon kaldığını ve aktif node diske erişemediğini bildirmektedir.

Event ID 1069 Detayı:

Cluster resource ‘Cluster Disk 2’ of type ‘Physical Disk’ in clustered role ‘Available Storage’ failed. The error code was ‘0x2’ (‘The system cannot find the file specified.’).

Cluster Log Detayı:

00002c38.00002210::2015/02/22-08:09:03.130 INFO  [RES] Physical Disk: HardDiskpQueryDiskFromStm: ClusterStmFindDisk returned device=’\\?\scsi#disk&ven_emc&prod_power&#{4a54205a-c920-4e28-88c5-9a6296a74b0b}&emcp&power3#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}’

00002c38.00002210::2015/02/22-08:09:03.130 ERR   [RES] Physical Disk: Failed to open device \Device\Harddisk24\ClusterPartition1, status 0xc0000034

00002c38.00002210::2015/02/22-08:09:03.130 ERR   [RES] Physical Disk: HarddiskpIsPartitionHidden: failed to open device \Device\Harddisk24\ClusterPartition1, status 2

00002c38.00002210::2015/02/22-08:09:03.130 ERR   [RES] Physical Disk: HardDiskpGetDiskInfo: GetVolumeInformation failed for \\?\GLOBALROOT\Device\Harddisk24\ClusterPartition1\, status 3

00002c38.00002210::2015/02/22-08:09:03.130 ERR   [RES] Physical Disk: HardDiskpGetDiskInfo: failed to get partition size for \\?\GLOBALROOT\Device\Harddisk24\ClusterPartition1\, status 3

Cluster Validation sonrası Cluster Log’a yansıyan Hata Detayı:

00002c38.000036a0::2015/02/22-08:04:24.330 WARN  [RES] Physical Disk <DBReports>: PR reserve failed, status 2

00002c38.000036a0::2015/02/22-08:04:24.330 ERR   [RES] Physical Disk <DBReports>: ResHardDiskArbitrateInternal: PR Arbitration for disk Error: 2.

00001d88.00003810::2015/02/22-08:04:24.330 DBG   [RCM] rcm::RcmApi::ResourceControl: (DBReports, GET_ID)

00001d88.00003810::2015/02/22-08:04:24.330 DBG   [RCM] rcm::RcmResource::Control: (DBReports, GET_ID)

00002c38.000036a0::2015/02/22-08:04:24.330 ERR   [RES] Physical Disk <DBReports>: OnlineThread: Unable to arbitrate for the disk. Error: 2.

00002c38.000036a0::2015/02/22-08:04:24.330 ERR   [RES] Physical Disk <DBReports>: OnlineThread: Error 2 bringing resource online.

Cluster Disk Rezervasyonunun Kaldırılması

A-) Çözüm için öncelikle tüm node’larda aşağıdaki komutu çalıştırınız.

Clear-ClusterDiskReservation -Disk 6 -Node node2 -Force

B-) Eğer A maddesi çözüm olmaz ise;

1.      Cluster servisini disable ederek Tüm node’ları kapatın

2.      Sadece birini açın

3.      Disk Management üzerinden diskleri online etin

4.      Tekrardan diskleri offline edin

5.      Cluster’ı forcequorum ile başlatın

6.      Diskleri online edin

7.      Sorun düzeldiğinde diğer node’larıda açın. Eğer sorun düzelmedi ise sunucuyu kapatıp Storage üzerinden rezervasyonun kaldırılması çalışılmalı

C-) Eğer B maddesi çözüm olmaz ise;

1.      Tek tek 1 node kalana kadar node’ları cluster’dan evict edin. (Eğer üzerinde SQL gibi bir servis varsa önce onu remove edin)

2.      Evict edilen node üzerinde aşağıdaki komutu çalıştırın

Clear-ClusterNode –Name node4 –Force

3.      Cluster’ı destroy edip sunucuyu restart edin

4.      Node acıdığında aşağıdaki komutu çalıştırın

Clear-ClusterNode –Name node4 –Force

5.      Aşağıdaki komut ile tüm disklerdeki rezervasyonu kaldırın

Clear-ClusterDiskReservation -Disk 6 -Node node2 –Force

6.      Disk Management üzerinden Disklerin online yapıp içini kontrol edin.

7.      Cluster’ı yeniden kurun.

8.      Diskleri Cluster’a ekleyin

Not:

Eğer hata alan resource SQL ise;

1)      Kuruluma başlamadan master disk içindeki master db yedeğini alın.

2)      Kurulum sonrasında SQL servislerini stop edip master db ile yenisinin ismini değiştirin

 

Kaynakça:

https://kb.netapp.com/support/index?page=content&id=3012956

http://blogs.msdn.com/b/clustering/archive/2013/05/24/10421247.aspx

http://blogs.technet.com/b/askcore/archive/2009/04/15/windows-2008-failover-cluster-validation-fails-on-validate-scsi-3-persistent-reservation.aspx

http://www.t10.org/scsi-3.htm

 

İlgili Makaleler

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Başa dön tuşu