Kullanıcıların Son Logon Oldukları Zamanı Öğrenme

21 Oca
2010

Windows Server 2003 Resource Kit Tools'u kurup, Start => All Programs => Windows Resource Kt Tools'u çalıştırın. Komut satırında regsvr32 actinfo.dll komutunu yazdıktan sonra Active Directory Users and Computers konsolundan istediğiniz kullanıcı hesabının üzerinde sağ tıklayıp properties diyerek o kullanıcının son logon olma zamanını görüntüleyebilirsiniz.

Active Directory DSRM İpucu

20 Oca
2010

NTDSUTIL Active Directory veritabanı ile ilgili düzenlemeler, restore işlemleri, fsmo rollerinin seize edilmesi, siteler arasındaki replikasyon trafiğinin zamanlamalarının ayarlanması  gibi birçok işlemde kullandığımız bir araçtır.

Domain Controller normal bir şekilde çalışırken Active Directory veritabanının birleştirilmesi, dosyaların farklı bir konuma taşınması gibi işlemleri yapabileceğimiz bir komut satırı aracıdır. Ama bazı durumlarda bu komut satırı aracını kullanmak için  Direcotry Service Restore Mode'u kullanmamız gerekebilir.

Directory Service Restore Mode'u başlattığımızda D.C safeboot_option değişkeninde "dsrepair" parametresini ayarlar.

Sisteminizde NTDSUTIL komutunu kullanırken aşağıdaki gibi bir hata alırsanız, DSRM'da değilsiniz demektir.

C:\WINDOWS>ntdsutil

ntdsutil: files

*** Error: Operation only allowed when booted in DS restore mode

 "set SAFEBOOT_OPTION=DSREPAIR" to override – NOT RECOMMENDED!

ntdsutil:

Eğer NTDSUTIL komutu ile sadece Directory Service Restore Mode'da yapmanıza izin verilen bir işlem gerçekleştirmek isterseniz  aşağıdaki komutla sistemi kandırabilirsiniz. :)

set SAFEBOOT_OPTION=DSREPAIR

 NOT : Yukarıdaki komutu cmd konsolunda çalıştırabilirsiniz. (Bu bir NTDSUTIL parametresi değildir)

Bu işlemi  sistemde değişiklik yapmak için kullanmanızı tavsiye etmiyorum. Unutmayın bu sadece Directory Service Restore Mode ile görüntüleyebileceğimiz bazı işlemleri DSRM'u açmadan yapabilmek içindir. Çalışan bir D.C üzerinde bu parametreyi girip değişiklikler  yapmak sisteminize zarar verebilir.

Operations Master Roller (FSMO)

12 Oca
2010

 Bugünkü makalemizde Flexible Single Master Operations (FSMO) rollerinden bahsedeceğim. Öcelikle bu rollerin ne olduğunu anlatıp arkasından da rollerin transfer edilmesi ve seize edilmesi işlemlerini anlatacağım.

Active Directory domain işlemleri Domain Controller olarak adlandırılan bilgisayarlar tarafından yerine getirilir. Domainlerde de bir ya da daha çok domain controller bulunabilir. Bu durumda bazı işlemler yalnızca bir domain controller tarafından yerine getirilir.

Active Directory domaini içindeki domain controller arasında yalnızca replikasyon amaçlı bir birliktelik olmaz. Replikasyonun dışında Operations Master roller olarak adlandırdığımız bazı roller de üstlenilir.

Operations Master roller, domain controller’lara single-master rolleri gerçekleştirmek üzere atanırlar. Yani bu rolleri üstlenen bilgisayarlar domainde tek başına (single-master) olarak çalışırlar.

NOT : Bir Active Directory forest’ında beş adet operations master rol yer alır ve bu roller bir domain controller’a verilebilir. Bazı roller tüm forest’larda yer almalıdır. Diğer roller de forest içindeki her domain’de yer almalıdır.

Operations Master roller olarak adlandırılan bu roller, forest ve domain kapsamında olmak üzere iki grupta toplanır:

Forest Kapsamındaki Master Roller

·     Schema master rolü: Schema’daki tüm güncellemeler ve değişiklikler bu rol tarafından kontrol edilir. Bir forest’ta yalnızca bir schema master yer alabilir.

 

·     Domain naming master rolü: Domainlerin isim babası. Bu role sahip olan domain controller, forest’a yeni domain’ler eklenmesi ya da domain’lerin çıkartılması işlemlerini kontrol eder. Bir forest’ta yalnızca bir domain naming master yer alabilir.

 

 

Domain Kapsamındaki Master Roller

RID (Relative Identifier) master rolü: Nesnelere ID verir. Bu role sahip olan domain controller, o domain’de yer alan tüm domain controller’lara Relative ID değerlerini verir. Böylece bir domain controller yeni bir kullanıcı, grup ya da bilgisayar nesnesi yarattığında o nesneye benzersiz bir security ID atanır. Security ID, bir domain security ID’den ve relative ID’den oluşur. Bir nesneyi domain’ler arasında taşımak için RID master rolüne sahip domain controller’ın bu işlemi gerçekleştirmesi (çalışıyor olması) gerekir.

·     PDC Emulator rolü: Domain’de Windows Server 2003 domain controller’ları ya da Windows NT backup domain controller’ları (BDC) varsa, PDC Emulator rolüne sahip olan domain controller, Windows NT PDC’si gibi görev yapar. Bunun dışında Client’ların password değişikliklerini işler ve güncellemeleri BDC’ye replike eder. Tüm domain controller’lar Windows Server 2003 ise, PDC emulator rolüne sahip olan DC diğer domain controller’lar tarafından yapılan password değişikliklerini kabul eder. Bir password değiştirildiğinde, tüm DC’ler arasında replike edilmesi zaman alır. Yanlış password nedeniyle gerçekleşen bir kimlik denetimi sorununda, DC’ler logon girişimini reddetmeden önce bu isteği PDC emulator’e gönderirler.  

 

·     Infrastructure master rolü: Bu role sahip olan domain controller, kendi domaini içindeki nesnelerin diğer domainlerden başvurulmasını sağlayan referans bilgileri günceller. Nesnelerin domainler arasında işlem görmelerini sağlar (onaylar). Bir domain’de aynı anda yalnızca bir tane infrastructure master yer alabilir.

 

Infrastructure master verilerini global katalog ile karşılaştırır. Global katalog replikasyon aracılığıyla diğer domainlerden güncellemeleri alır. Infrastructure master, verinin güncel olmayan bir veri elde ederse güncel verilerin global katalogdan ister. Infrastructure master ardından güncel verilerin domain içindeki diğer domain controller’lara dağıtır.

ÖNEMLİ: Infrastructure master ve global catalog rolleri aynı domain controller üzerinde olmamalıdır. Bu durum infrastructure master’ın güncel olmayan bir veriyle karşılaşmasını engeller. Bu durumda diğer domain controller’lara güncel bilgi ulaştırılamaz.

Infrastructure master ayrıca gruplar ve kullanıcılarla ilgili bilgileri de günceller. Grup üyeleri değiştiğinde ya da adları değiştirildiğinde gerekli güncellemeleri yapar. Grubun diğer domainden olan üyeleri değiştirildiğinde (adı ya da üyesi değiştirildiğinde ya da taşındığında) gerekli güncellemeleri yapar.

Mevcut Master Rolleri Görmek

RID master, PDC emulator ve infrastructure master rollerini görmek için;

Active Directory Users and Computers konsolunu açıyoruz ve domain adının üzerinde sağ tıklayarak Operations Master seçeneğini seçiyoruz.

Operations Masters ekranında aşağıdaki seçenekleri görebilirsiniz.

 

  •  RID sekmesinde RID master’ın adı görülür.
  •  PDC sekmesinde PDC emulator’ün adı görülür.
  •  Infrastructure sekmesinde infrastructure master’ın adı görülür.

 FSMO Rolleri

 Domain naming master rolünügörüntülemek için ise Active Directory Domain and Trusts konsolunu açıyoruz ve Active Directory Domain and Trusts üzerinde sağ tıklayıp Operations Master seçeneğini tıklıyoruz.

Schema master rolünü değiştirmek için ise Active Directory Schema snap-in’i kullanılır.

Schema Master rolünü görüntülemek için regsvr32 schmmgmt.dll komutunu komut satırında çalıştırmayı unutmayın.

Schema Master rolünü görüntülemek için;

MMC konsolundan Active Directory Schema’yı açın ve  Active Directory Schema üzerinde sağ tıklayın ve Operations Masters’ı seçin.

NOT: Birden çok domain bulunan forest’larda bu role ancak root domainden (root DC) erişilir.

Rollerin transfer edilmesini anlatacağım makalede görüşmek üzere. İyi çalışmalar.

Clustering Türleri III — Network Load Balancing

24 Eyl
2009

Cluster konulu makale serisinin son adımında Network Load Balancing’ten bahsedeceğim.

NLB bir quorum kullanmadığı için node’larda depolama ve ağ gereksinimlerine ihtiyaç duymaz. Cluster içindeki bir node çöktüğünde NLB otomatik olarak yeni gelen istekleri diğer node’lara yönlendirir. Eğer bakım için bir node’u devre dışı bırakırsanız NLB, node devre dışı olmadan önce var olan oturumların tamamlanmasına izin verir. Bu da son kullanıcıların bu durumdan zarar görmesini engeller. NLB aynı zamanda gelen istekleri uygun gördüğü tarafa yönlendirerek güçlü donanıma sahip sunucular ile yetersiz haldeki sunucuların bir arada kullanılabilmesini sağlar, eldeki tüm donanımların etkin kullanımına yardımcı olur.
 

NLB genellikle firewall’lar, proxy, FTP veya web sunucuları için sağlamlık ve ölçeklenebilirlik sağlamada kullanılır. NBL’yle cluster yapılan diğer uygulamalar sanal VPN noktaları, streaming media sunucuları ve terminal servisleridir. Her Windows 2003 sürümünde bulunur ve 32’ye kadar node’tan oluşan clusterlarda uygulanabilir.
 

NLB yapılandırması Network Load Balancing Manager snap-in’i veya wlbs.exe ya da nlb.exe adlı konsol araçlarıyla gerçekleştirilir.
 

Temel olarak, NLB açıldığında, NLB sürücüsü NIC sürücüsü ile IP protokolü arasına yerleşir ve tüm cluster node’larına gelen her paketi alıp inceler. Paket kablodan kümeye geldiğinde her node paketi alır, inceler ve cluster çapında belirtilmiş kurallara göre paketi üst katmanda bulunan IP protokolüne iletir veya paket daha NLB sürücüsündeyken dışarı atılır. Böylece trafik nodlar arasında paylaştırılır. Kısaca tüm node’lar clustera  gelen trafiği alır; ama bazıları cevap verir.
NLB clusterları iki farklı modda çalışabilir. Birincisi, aynı zamanda varsayılan mod olan Unicast Mode’dur. Unicast mode’da clusterı oluşturan node’larca kullanılan bir tek sanal MAC adresi vardır. Bu adres daima 02-BF ile başlar. Tüm cluster üyelerinin bu tek adresi NLB sürücüsü sayesinde kullanması ağ kartı üzerinden görüşebilmelerini engeller. Örneğin; node a node b’ye bir paket gönderirken hedef ve kaynak MAC adreslerini aynı yazar. Bu paketi alan nod b kaynak MAC adresi ile paketin hedefi olan kendi MAC adresini karşılaştırınca bunların aynı olduğunu görüp bir hata oluştuğunu düşünerek paketi atar. Sonuç olarak unicast mode’ta çalışan NLB kümesi üyeleri NLB çalıştıran ağ kartı üzerinden birbirleriyle görüşemezler. Bu sorunu ortadan kaldırmak için iki yöntem vardır. Birincisi node’lara ikinci bir ağ kartı takmaktır. İkinci ağ kartı NLB clusterıyla aynı ağa veya farklı ağa bağlı olabilir. Node’lar arasında ek bir bağlantı yapılması yeterlidir. İkinci çözüm ise Multicast mode’u kullanmaktır.

Multicast mode’dayken node’lar hem sanal MAC adresini hem de kendi MAC adreslerini kullandığından node üzerinde bir tek ağ kartının bulunmasına rağmen birbirlerine gönderdikleri paketleri işleyebilirler. Multicast mode’da paylaşılan ortak ve sanal MAC adresi daima 03-BF ile başlar.

Sistemdeki sürekliliğin sağlanması için cluster node’larının birbirleriyle sürekli haberleşmesini sağlamak gerekir. NLB algoritması clusterdaki node sayısı, varsa belirlenen port kuralları ve cluster IP’lerini göz önüne alarak hesaplamaları yapar ve gelen trafiğin node’lar tarafından kabul veya red edilmesini sağlar. Bu hesaplama sürecine Yakınsama (Convergence) adı verilir. Yakınsamada Heartbeat (nabız) denilen paketler kullanılır. Bu paketler her node’ta yalnızca NLB çalıştıran ağ kartı tarafından saniyede bir kez atılan 1,5 kb’lık broadcast paketleridir. Bu süre registry’den değiştirilebilir ancak tüm node’larda aynı olmalıdır. Varsayılan ayarlara göre eğer node arka arkaya 5 heartbeat kaçırırsa clusterdaki diğer üyeler o node’un devre dışı olduğuna, kümeden düştüğüne karar verirler. Ardından yeni üye sayısına göre NLB algoritması yeniden hesaplanır, yakınsama başlar ve 3 saniye sürer. Bu değer de registry’den değiştirilebilir ancak her node’ta aynı olmalıdır.

Özet olarak, clustera yeni bir node eklendiğinde bunun tespit edilip gelen yükün clustera tekrar paylaştırılması 3 saniye sürer. Bir node devre dışı kaldığında ise bunun diğer node’larca fark edilmesi ve yakınsamaya başlanması için 5 heartbeat yani 5 sn. daha geçer. Toplamda 8 sn. sonunda yakınsama tamamlanacak ve sistem yeni yapısına göre hareket etmeye başlayacaktır.

NLB’nin yakınsama hesaplamasında bir diğer önemli etken ise affinity yani eğilim ayarıdır. None, Single ve Class C olmak üzere 3 seçeneği olan affinity değerine bakarak NBL; node’lara gelen IP paketlerinin kabul edilip edilmeyeceğine karar verir. Affinity ‘None’ olarak ayarlandığında gelen paketler kaynak port ve kaynak IP’lerine bakılarak işlenir. Web sunucusu çalıştıran clusterlarda  bu ayar kullanılır. Single affinity ise gelen trafiği sadece kaynak IP adresine göre dağıtır ki bu tür terminal sunucular için en uygunudur. Son seçenek olan Class C ayarında ise aynı C sınıfı alt ağındaki IP adresine sahip kaynaklardan gelen tüm paketler aynı node’a yönlendirilir. Bu da genellikle proxy sunucuların yük dengelemesinde yarar sağlamaktadır.

Cluster makalelerinin sonuna geldik. Bu seride uygulama yapmak yerine daha çok teorik adımlardan bahsettim. Sizden gelen istekler doğrultusunda Server Cluster ya da Network Load Balancing konularında uygulamalarda gerçekleştirebilirim. Umarım yararlı bir seri olmuştur. herkese iyi çalışmalar.

Clustering Türleri II – Server Cluster

23 Eyl
2009

Bir önceki makalemde cluster nedir ve cluster türleri nelerdir bunlara değinmiştim. Bu makalemde ise cluster türlerinden Server Cluster’ı anlatacağım. Server Cluster’da önce cluster içinde node yani birim olarak rol oynayacak olan 2 ila 8 arasında sunucu yapılandırılır. Ardından cluster yapılacak uygulamanın ihtiyaç duyduğu kaynaklar yapılandırılır. Bu kaynaklar ağ isimleri, IP adresleri, uygulamalar, servisler veya disk sürücüleri olabilir. Sonuç olarak cluster çalışmaya başlar ve gelecek istekleri işlemeye başlar.

Çoğu cluster yapılmış uygulama ve onlara bağlı kaynaklar tek bir zamanda sadece bir cluster node’una işlenmek üzere atanır. Eğer Server Cluster ilk node’un bakım, çökme gibi herhangi bir nedenden ötürü devre dışı olduğunu belirlerse yedekteki diğer node’ta uygulama çalıştırılır ve istek hemen bu yedekteki node’a aktarılarak hatanın önüne geçilir.

Cluster yapılan servislerin çoğu genellikle tek bir zamanda sadece bir node’ta çalıştırılmasına rağmen aslında bir cluster aynı anda birçok servisi donanımdan daha çok yararlanmak için çalıştırabilir. Microsoft SQL Server gibi bazı uygulamalar birçok cluster node’unda eş zamanlı olarak çalışabilmektedir.

Cluster’daki node’lar cluster yapılmış uygulamanın kime ait olduğunu izlemek için bir quorum kullanır. Quorum cluster işlemine tabi tutulmuş bir uygulama için birincil node tarafından yönetilmesi zorunlu olan bir depolama aygıtıdır ve tek bir zamanda sadece bir node onu yönetebilir. Fail-over durumunda ise yedekteki node quorum’un yönetimini devralır. Tüm cluster node’ları tek bir depolama aygıtına bağlandığında quorum bu aygıt üzerinde yaratılır. Bu tür clusterlara Windows 2003’te single quorum device server cluster yani tek quorum’lu server cluster denmektedir.

Node’ların tek bir depolama aygıtına bağlanması verinin yönetiminin yedek node’a aktarılmasındaki zorluğun ortadan kalkmasını sağlar ancak bu yöntemin de zayıflıkları vardır. Eğer depolama aygıtı bozulur veya çökerse tüm cluster çöker. Aynı şekilde storage area network (SAN) yani depolama alanı ağı çökerse tüm cluster çöker. Depolama aygıtı veya SAN; her ikisinin de asla çökmeyeceğini garanti etmeye kalksak dahi çökecek bir şey daha vardır o da sistemin bulunduğu ortamda meydana gelebilecek sel, yangın, deprem, elektrik kesintisi gibi felaketlerdir.

İşte bunun da önüne geçmek için Majority Node Set (MNS) server cluster adlı yapıya başvurulur.Quorum bu defa her bir node’da doğrudan yerel olarak bağlanır ve her bir node’taki quorum’da ağdaki replikasyon sayesinde aynı veriler depolanır. Şekilden de anlaşılabileceği üzere node’lar sadece tek bir ağa ihtiyaç duyduğu için ağ LAN, WAN veya uzak şehirlerdeki cluster node’larını cluster’a bağlayan VPN yapısına sahip olabilir, bu da clusterın coğrafik engelleri aşmasını sağlar. Bununla birlikte etkin bir fail-over başarımı için MNS yapısında clusterdaki node’ların en az yarısından çoğunun sürekli çalışır halde olma zorunluluğu vardır. Oysa single quorum device server cluster’da bir tane node’un çalışır olması yetmektedir.

Server Cluster makalesinin de sonuna geldik. Cluster türlerinden Network Load Balancing ile cluster makale serimi tamamlayacağım. İyi çalışmalar.