Cluster/Disk, Persistent Rezervation Süreci

Bügünlerde başımıza gelen musibetlerin getirdiği makale tadında post :

Cluster Servisi shared nothing çalışır bunun bize bakan anlamı özellikle disk kaynağının sahipliğinin tek bir nod olması şeklindedir. Bu sahipliği sağlayan mekanizma SCSI 3 komutları ile persistent rezervation işlemidir yani bu komut setleri ile diskin sahipliğinin ilgili noda tahsis edilmesidir.

Cluster servisi içerisinde persistent rezervasyona giden sürec; clusdisk.sys driverı ile başlayıp buradan OS seviyesinde disk.sys, mpio ve ilgili vendora(Emc,Hp,Ibm vs..) ait DSM sürücüsüdür. DSM driver ilgili storage için PR taleplerinin registrationundan sorumlu olup, çoklu pathlerden üzerinden nodların rezervasyon taleplerinin kaydedilmesini yönetir.

Örnek olarak 2 nodumuz var ve bunlar üzerinde 2 portlu HBA ‘ımız mevcut. Nodlar ve HBA üzerindeki her bir interface registration tablosunda kendisine ait uniq bir numara ile kayıtlı durumda olurlar. Node1’in HBA’daki 1. portu (HBA1) diskin sahibi olması durumunda tabloada aşağıdaki gibi kendisini ilk satırda kayıt altına alır. HBA1’de oluşan bir problem sebebi ile fail etmesi durumunda kendisi ile ilişki vendor DSM konfigurasyon stack komutlarını kullanarak otomatik olarak disk resourcelarını fail ederek failover sürecini başlatır.

Nodlar her 3 sn.de bir registration tablosuna bakar ve rezervasyon kontrolu yapar fakat bu tabloya Node1 (defender) HBA1 deki arızadan dolayı registration yapamadığı için 2.Node (challenger) 2. 3 sn.de rezervasyon tablosunun boş olduğunu görerek kendisi rezervasyon koyar ve diskin sahipliğini elde eder.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s