Microsoft’un yeni işletim sistemlerinde sürekli olarak güvenlik seviyesini arttırdığını biliyoruz, Vista ve Server 2008 işletim sistemlerinde de güvenliğin son derece ön planda olduğunu söylemek mümkün. Özellikle Group Policy lerde olağanüstü bir genişleme ve yenilik ilk bakışta göze çarpıyor. Ben de bu makalemde sizlere yeni versiyon işletim sistemlerindeki Group Policy dosyalarının farklarını ve olası hataların önlenmesi için neler yapılması gerektiğini anlatacağım.Daha önceleri .adm formatında olup sadece kendi platformunda çalışabilen Group Policy dosyaları ( En fazla notepad ile açabiliyorduk ki bu bizim düzenlememiz için düşünülmemiş.) artık .admx formatında ve xml programlarıyla görüntülenebiliyor.

Dosyaların arasında ki en büyük ve en önemli farklardan biri ise şu; önceki işletim sistemlerinin kullandığı Group Policy dosyalarında sadece işletim sisteminin kendi varsayılan dili kullanırken yeni Group Policy dosyaları belirtebileceğimiz farklı dillerde güncellenebiliyor. Bu da .admx uzantılı dosyaların çoklu dil desteği sağlaması anlamına geliyor.

Bununla beraber Group Policy dosyalarının yerinin de değiştiğini belirtmekte fayda var. Daha önce %systemroot%\inf konumunda bulunan dosyalar artık %systemroot%\policyDefinitions klasöründe bulunmaktadır ve aşağıda ki örnekte olduğu gibi varsayılan dil altında bütün Group Policy dosyalarının bir kopyası bulunmaktadır.

Dosyaların içerik farklılıkları hakkında bir ön bilgi sahibi olduktan sonra eski Group Policy dosyalarının yenilerine uyarlamasına geçebiliriz. Tabi ki yeni kuracağımız sistemde tam manasıyla bir alt yapı değişikliği yapacak olursak dosyaları da uyarlamaya ihtiyaç duymayız. Fakat eski işletim sistemleriyle beraber çalışacağımızı varsayıyorum. Açıkçası yeni sürüm işletim sistemine sahip server ve client ları eklemeden önce eski server ve client larımızın burada bahsettiğim yeni ayarlar ve dosya türlerinden etkilenmemesini düşünmek olanaksızdır.

Bu noktada .adm dosyalarının uzantılarını .admx olarak mı dönüştürmemiz gerekecek diye düşünülebilir. Elbette kesinlikle hayır, tahmin ettiğiniz gibi Server 2008 ve Vista da bulunan Group Policy Editor , Vista, Server 2003, 2000 ve Xp de kullanılan .adm dosyalarını düzenleyebilecek şekilde tasarlanmıştır. Adm şablonunun düzenlemenin açıklaması ise şu; Group Policy objelerini ara yüzden düzenlerken bu dosyaların üzerine yazıyorsunuz demek oluyor, örnek olarak domain ortamında ki kullanıcıların Windows Movie Maker ı kullanmalarını yasaklamak için Group Policy ayarlarını yapılandırdınızda sonuç olarak ilgili .adm dosyasını aşağıdaki gibi yapılandırmış olursunuz.

CATEGORY !!MovieMaker

POLICY !!MovieMaker_Disable

#if version >= 4

SUPPORTED !!SUPPORTED_WindowsXPSP2

#endif

EXPLAIN !!MovieMaker_Disable_Help

KEYNAME “Software\Policies\Microsoft\WindowsMovieMaker”

VALUENAME “MovieMaker”

VALUEON NUMERIC 1

VALUEOFF NUMERIC 0

END POLICY

END CATEGORY

Şimdi örnek bir yapı oluşturalım, yalnız ondan önce eğer “file replication” servisinin transfer zamanını beklemek istemiyorsanız bu yapıyı PDC üzerinde oluşturmanızı tavsiye ederim.

Aşağıdaki yapıyı oluşturmaktaki amaç Server 2008 ve Vista nın 2000–2003 ve Xp de ki gibi her bir Group Policy için ayrı klasörler açmaması ve dosyaları tek bir merkezi klasörde toplaması. Merkezi klasörler grubu oluşturarak aynı domain yapısındaki Domain Controller ların da kendi içinde dosya oluşturması yerine aynı merkezi kullanması ve dosyaları bu dizinden almasını sağlamış oluyoruz.

Yukarıda belirttiğimiz gibi İlk önce klasörleri oluşturalım.

%systemroot%\sysvol\domain\policies\PolicyDefinitions
%systemroot%\sysvol\domain\policies\PolicyDefinitions\EN-US

Daha sonra varsayılan klasördeki dosyaları almanız için önceden hazırlanmış Xcopy komutunu kullanabilirsiniz. ( Bat olarak kaydedebilir ya da direk komut satırına kopyalayabilirsiniz. )

CD C:\
Xcopy %systemroot%\PolicyDefinitions\* %systemroot%\sysvol\domain\policies\PolicyDefinitions\
Xcopy %systemroot%\PolicyDefinitions\en-us\* %systemroot%\sysvol\domain\policies\PolicyDefinitions\en-us

Daha sonra gpmc.msc komutu ile Group Policy Object Editor u açın ve yeni bir Group Policy oluşturun , objeyi modifiye edip kapatın ve dosyanın yeni formatta modifiye edildiğini kontrol edin.

Ve herhangi bir member server üzerinde dosyaların doğru dizinde konumlandırıldığını kontrol edin.

Böylece eski sistem Group Policy dosyalarınızı kaybetmeden veya yeni dosyalarla çakışmaya uğramadan kullanabilirsiniz.

Bir başka Server 2008 makalesinde daha görüşmek üzere…

Windows Xp Pro ve 2000 Pro ile birlikte gelen IIS Server yazılımı ile bilgisayarımızda sadece tek bir web sitesi yayınlayabiliyoruz. Fakat bu kısıtlama Windows Server ürün ailesi için geçerli değil. IIS Server üzerinde dilediğimiz kadar web sitesi yayınlayabiliriz ve bunların içerikleri birbirinden tamamen farklı olabilir. Peki, gelen bir isteğin hangi web sitesine ait olduğunu IIS nasıl anlayacak? IIS Server gelen web isteklerini 3 farklı kıstasa göre değerlendirip birbirinden ayırabilir;

1-) IP Adresi

2-) Port Numarası

3-) Host Header Bilgisi

Şekilde bir web sitesinin özellikleri görünmektedir. Yukarıdaki bilgiler bu bölümden değiştirilebilir.

IIS üzerinde aynı ip üzerinden birden fazla web sitesini yayınlayabilmek için farklı port numaraları kullanabiliriz. Örneğin ilk web sitemiz standart http portu olan 80 nolu portu kullanırken ikinci site 81 nolu portu kullanabilir. Fakat bu kabul edilebilir bir durum değildir çünkü böyle bir durumda sitemizi ziyaret etmek isteyen kullanıcılar web tarayıcılarına http://www.sitemiz.com:81 gibi bir url yazarak siteye erişmek zorunda kalacaklar. bu durumun önüne geçmek için IIS Host Header bilgisini kullanır. Farklı siteleri farklı DNS domain isimleriyle yayınlarız. Bu DNS domain isimleri (örn; www.aslankara.com) aynı zamanda o sitenin Host Header bilgisini oluşturur. IIS aynı ip’nin 80 nolu portuna gelen istekleri bu bilgiden ayırt eder ve birçok siteyi sorunsuz biçimde yayınlama imkânı sağlar.

Fakat işin içine SSL girdiği zaman Host Header bilgisi artık kullanılamaz. IIS SSL ile gelen güvenli web isteklerini karşılarken Host Header bilgisine ulaşamayacağından yukarda anlattığımız durum söz konusu olur ve bir ip üzerinden aynı porttan (standart ssl portu 443) sadece bir güvenli web sitesi yayınlayabiliriz. Yeni bir web sitesi için yeni bir ip ye yada yeni bir porta ihtiyaç vardır. Yeni port kullanarak çözmek pek mantıklı olmayacak çünkü kullanıcıların sitemize erişmesi web adresinin haricinde birde port numarası girmeleri gerekecek ki bu reel hayatta pek doğru bir çözüm değildir. Burada yapılması gereken eğer gerçekten böyle bir ihtiyaç varsa ve birden fazla farklı web sitesi IIS üzerinde SSL kullanılarak yayınlanmak isteniyorsa her site için farklı ip adreslerinin kullanılması gerekmektedir.

Şirketimize ait web sitelerini tek IIS üzerinden güvenli bir şekilde yayınlamak için bir çözümde aynı SSL sertifikasını birden fazla site için kullanmak olabilir. Eğer tek sertifika birçok site için kullanılabilirse yukarıdaki Host Header sorunu ortadan kalkar. Fakat burada da bir problemimiz var. SSL sertifikaları talep edilirken “Common Name” başlığında sitemizin Host Header bilgisini girmemiz gerekmektedir. Eğer bu bilgide bir hata olursa İnternet Explorer web sitesini her açtığında güvenlik uyarısı verecektir. Şekilde bu uyarı görülmektedir.

Her site için ayrı bir sertifika kullanabilseydik bu bir sorun olmazdı fakat IIS yukarıda bahsettiğim sebeplerden sadece tek bir SSL sertifikasını kabul eder. Burada da imdadımıza “Wildcard Common Name” yetişmektedir. Sertifikayı isterken Host Header bilgisini yazdığımız Common Name bölümüne *.aslankara.com gibi bir ifade yazarak tüm sub domainleri kapsayan bir sertifika çekebilir ve tüm web sitelerimiz için kullanabiliriz. Şimdi adım adım bu işlemi gerçekleştirelim. Örneğimde banka.aslankara.com ve alisveris.aslankara.com isimli iki web sitesini aynı sertifikayı kullanarak yayınlayacağım.

Şekilde görüldüğü üzere standart halde her iki web sitesi 80 nolu porttan farklı Host Header bilgileri ile sorunsuz bir şekilde hizmet veriyor. İlk iş olarak alışveriş sitesi için bir sertifika talebinde bulunuyorum. Bunun için aşağıdaki adımları izlememiz gerek.

Alışveriş web sitesinin özelliklerinde Directory Security tabında Server Certificate butonuna tıklayalım. Daha sonra karşımızdan gelen sihirbazı aşağıdaki şekilde tamamlayalım. Common Name sorusuna ise verdiğimiz cevaba lütfen dikkat.

Bu işlemler tamamlandıktan sonra sertifikamızı görüntülemek için “View Certificate…” butonuna basıp durumu görelim.

Görüldüğü gibi sertifika *.aslankara.com domaini için geçerli.

Artık bu sitemizi SSL’li bir şekilde açabiliriz.

Şimdi sıra geldi ikinci web sitesini güvenli bir şekilde yayınlamaya. Bunun için farklı bir sertifika almak yerine varolan sertifikamızı örnekteki banka sitesi içinde kullanmak üzere atayacağız. Yapmamız gereken yine site özelliklerinde Directory Security tabına gelip Server Certificate butonuna tıklamak. Bu sefer karşımıza gelen sihirbazı aşağıdaki adımları uygulayarak bitiriyoruz.

İkinci sihirbazı da yukarıdaki şekilde tamamladıktan sonra her iki web sitemizde 443 nolu porttan çalışmaya başlayacak. Yada biz öyle olduğunu sanacağız çünkü IIS Server’ı yada sadece banka sitesini restart ettiğimizde göreceğiz ki banka sitesi start olamıyor. Restart etmeden tarayıcımız da https.//banka.aslankara.com yazsak dahi ilk siteyi açacaktır. Bu probleminde üstesinden gelmek için yapmamız gereken IIS metabase’deki bir değeri değiştirmektir. Metabase IIS in ayarlarının saklandığı bölümdür. IIS’in registry’si gibi düşünülebilir. Bu ayarı yapmak için aşağıdaki komutu çalıştırmamız gerekmektedir.

cscript.exe adsutil.vbs set /w3svc/<site identifier number>/SecureBindings “:443:<host header>”

Komutu c:\inetpub\adminscripts dizini altında çalıştırmalıyız zira adsutil.vbs dosyası bu dizindedir. Host Header bölümüne sitenin domain adı yani örnekte banka.aslankara.com yazılmalıdır. Site Identifier Number bilgisi ise IIS üzerinde görülebilir.

Komutu aşağıdaki şekilde koşturduktan sonra sitemiz kullanılmaya hazır olacak.

Artık sitemizi start edip güvenli bir şekilde kullanmaya başlayabiliriz. Öncesinde IIS Server Servisini restart etmeniz gerekebilir.

Yazımızın sonuna geldik. Bir başka makalede görüşmek üzere.

WebFarm
Internet Information Server Clustering (Bölüm-1)

Kurumların büyüme ölçeklerini göz önünde bulundurarak söylemek gerekirse internet ya da intranet üzerinden verdikleri/verecekleri hizmetler bakımından sürekli artan bir ihtiyaç söz konusudur. Kurum içinde bu hizmetleri kullanacak personel sayısı arttıkça ya da kurumun dışarıya vermek istediği hizmetlerin boyutu -ister kullanıcı, isterse teknoloji bazlı olsun- arttıkça kurumlar server hizmetleri bakımından yeni yapılara ihtiyaç duyarlar. Günümüzün bu konudaki gözde teknolojilerinden biri “cluster” (küme) yapılardır. Bu makalede internet/intranet yani web üzerinden verilecek sistemlerdeki kullanılabilirlik, ölçülebilirlik ve performans açısından Web Server’ların Cluster yapısı anlatılacaktır.

Web Sunucularının cluster(kümeli) şeklinde çalışması için çeşitli tasarımlar geliştirilmiştir. Bu yapılar “WebFarm” şeklinde isimlendirilir. Birden çok sunucu ile ya da aynı anda birden çok süreç üzerinde eş zamanlı olarak çalışmak söz konusu olunca bu konuda çeşitli terimler ortaya konmuştur. Burada durumu biraz daha netleştirmek için Webfarm Cluster yapısının haricindeki “WebGarden” denilen başka bir yapıyı da açıklamakta fayda görüyorum. Bu yapı WebFarm’dan farklı olarak tek bir sunucu üzerinde aynı web hizmetinin devamlılığını sağlamak için birbirine eş birden fazla process oluşturarak belli bir application pool’da bulundurur ve bu yöntemle hataya karşı dayanıklılığı (Fault tolerancy) sağlar. WebFarm yapısı bundan tamamen farklı olarak birden fazla server ile “Fault tolerancy-Scalability- High Availability” ögelerini yerine getirir. Bu makelenin tümünde Windows Server 2003 R2 işletim sistemi kurulu olan sunucular kullanılmıştır. Ayrıca Internet Information Server 6.0 (IIS-6.0), Network Load Balancing Manager (NLB), Disturbed File System Management (DFS), SQL-2005, Windows Xp/Vista ayrıca çeşitli scriptler senorya gereği kullanılmıştır. Bu clustering senaryosu yukarıda sözü geçen uygulamaların başka sürümlerinin kombinasyonları ile de kullanılabilir, makale boyunca yeri geldiğince bu konuya ve bunu gerçekleştirirken karşılaşılabilecek sorunlara değinilecektir.

Konuya doğrudan girmek yerine bu bölümde cluster konusunda temel bilgiler vermeyi daha doğru buluyorum. Cluster(kümeleme) yöntemi, yukarıda WebFarm üzerine bahsettiğim gibi birden çok sunucunun belli bir amaç için beraber ya da duruma göre sırayla, belirlediğimiz sunusu kümesi içerisinde toplanarak çalıştırılmasıdır(kümelenmesidir). Bu sunucu kümesinin üyesi olan her sunucudan birine “Node”(düğüm) denir. Cluster uygulamasında yer alan node’lar tek bir birim gibi çalışarak Microsoft Internet Information Services (IIS), Exchange Server gibi uygulamalara yönelik hizmetleri yüksek kullanılabilirlik(high avaibility) ile kullanıcılara sunar. Böylelikle küme oluşturmak cluster içindeki node’ları tek tek yönetmek yerine, uygulamaya yönelik olarak tek bir sistem halinde yönetilmesini sağlar. Bunun yanı sıra bu durum kullanıcı tarafı temel alınarak incelenirse, kullanıcılar sistemin cluster şeklinde çalışıp çalışmadığını çoğu durumda sezemezler, bu da cluster içindeki sunucuların tek bir sistem şeklinde çalıştığının kanıtıdır ki cluster yapmanın en önemli amaçlarından biri budur.

Cluster uyumlu olan uygulamalara örnek vermek gerekirse:

· DFS (distributed File System)

· DHCP

· Exchange Server

· File Server görevleri (dosya paylaşımları)

· IIS (Internet Information Services)

· Microsoft Distributed Transaction Coordinator (MS-DTC)

· MSMQ (Microsoft Message Queuing)

· NNTP (Microsoft News Transfer Protocol)

· Printer Pooling

· SMTP

· SQL Server

· WINS

Bu uygulamalar farklı cluster tipleri ile uygulanabileceği gibi beraberce de belli bir sistem için kullanılabilirler. Bunların yanında farklı uygulamalar da kümeli çalışabilirler(Oracle Server vs.) Cluster ortamının oluşabilmesi için IP tabanlı protokollere ihtiyaç vardır. Uygulamalar iletişim kurmak için IPX NetBEUI tarzındaki protokolleri kullanamazlar.

Daha önceden WebFarm senaryosunda kullanılacak uygulamalardan bahsederken Windows Server 2003 (R2) demiştik, burada bu Server2003’ün desteklediği 3 çeşit cluster tipi vardır:

1- NLB (Netwok Load Balancing), sunuculara gelecek olan yükü network üzerinde, belirlediğimiz kurallara yönelik olarak (affinity) paylaştıran, ağ yükünün dengelenmesi şeklinde gerçekleşir. NLB ile TCP (Transmission Control Protocol) haricinde UDP (User Datagram Protocol) ve GRE (Generic Router Encapsulation) tarfikleri için de yük dengelemesi sağlanabilir. Webfarm uygulamasında kullanacağımız cluster tipi budur. Ayrıca Microsoft, Web Sunucuları için cluster yaparken en uygun yöntemi NLB olarak önerir.

2- CLB (Component Load Balancing), COM+ kullanan uygulama bileşenlerinin dinamik bir şekilde yük dengelemesini sağlar. Yine yüksek kullanılabilrlik-ölçeklenebilirlik(scalability) açısından birçok Node üzerinde yük dengelemesi sağlar.

3- MSCS (Server Clustering), Sunucu kümesi olarak adlandırılabilir. Cluster Administrator arayüzü kullanarak yapılandırılır. Yüksek kullanılabilirlik-Ölçeklenebilirlik-Güvenilirlik açısından uygulamalar üzerinde hataya karşı dayanıklılık (fault tolerancy) sağlar. Arka uç sunucularda (SQL Server vs.) kullanımı uygundur.

Her küme oluşturma teknolojisinin belirli bir amacı vardır ve farklı gereksinimleri karşılayacak şekilde tasarlanmıştır. NLB, web hizmetleri nedeniyle oluşabilecek kısıtlamaları engellemek amacıyla tasarlanmıştır. CLB, web tabanlı uygulamaların ölçeklenebilirlik ve yüksek kullanılabilirlik ihtiyaçlarını karşılayabilmek için tasarlanmıştır. MSCS, veri bütünlüğünü korumak(integrity) ve yerinde çalışma desteği sağlamak amacıyla tasarlanmıştır.

Konuya daha geniş bir açıyla bakarsak, bu cluster hizmetleri beraberce kullanılabilir ve çoğu durumda da bu sistemin planlanan verimde çalışması için bir gerekliliktir. Yukarıda bahsi geçen üç cluster tipinin beraberce kullanılabileceği en genel senaryo bir web sitesinin yayınlanması olacaktır. Webfarm’ın adından işte burada söz etmeye başlayarak örneklerle devam edelim. Ön uç sunucular olan Web sunucularda (IIS) NLB yani Webfarm, orta katman sunucularda CLB ve arka uçta olan veri tabanı hizmetlerinde MSCS kullanılarak (SQL Clustering) bir sistem tasarlanabilir. Bu sistem genel hatlarıyla aşağıdaki taslağa benzeyecektir, zaten ilerleyen bölümdeki uygulamaları bu taslak üzerinden yola çıkarak yapacağız.

Cluster yapıları, Farm (çiftlik) ya da Paket adı verilen ikili gruplar olarak kullanılır. WebFarm bu gruplardan Farm yapısının Web uygulamalarına yönelik olarak kullanılış biçimi olduğu için bu şekilde isimlendirilir. Farm yapıları, benzer sistemler çalıştıran ama genelde veri paylaşmayan bir sunucu grubudur. Bunlara “Farm” adı verilmesinin sebebi, kendilerine iletilen tüm istekleri, verilerin sucular üzerinde yerel disklerde saklanan birebir kopyalarını kullanarak işlemeleridir. Verileri paylaşmak yerine birebir kopyalarının kullandıkları için node’lardan her biri özerk biçimde çalışır ve bunlara “Copy” (kopya) adı verilir. Paket ise bir arada çalışan ve bölümlenmiş verileri paylaşan bir grup sunucudur. Bunlara Paket denmesinin sebebi ise hizmetleri yönetmek ve korumak için birlikte çalışmalarıdır. Bir paketin üyeleri bölümlenmiş verilere erişimi paylaştığı için, işletim modları benzersizdir ve genelde paketin tüm üyelerinin bağlı olduğu disk sürücülerindeki paylaşılan verilere erişirler.

Çoğu durumda Web ve Uygulama(Application) hizmetleri Farm olarak, Arka uç veri tabanları ve kritik destek hizmetleri ise paket olarak düzenlenir. WebFarm yapısı birden fazla Farm’ın bileşimi olarak tasarlanabilir. Aynı veriler farm yapısındaki tüm Node’larda çoğaltılır ve her sunucu, kendisine gönderilen istekleri verilerin yerel kopyalarını kullanarak işleyebilir. Örneğin, NLB kullanan ve her birinde web sitesine ait olan verilerin yerel kopyası bulunan çok sayıda web sunucusu vardır. Elbetteki bir Farm içindeki sunucu sayısında da bir üst sınır vardır, bu konudan önümüzdeki paragraflarda bahsedeceğim. Biz oluşturduğumuz taslak üzerinden çalışma devam edeceğiz. Senaryomuzda WebFarm içerisinde iki adet web sunucuyu kümeli olarak çalıştıracağız. Aşağıdaki şema konu hakkında genel bir bilgi verecektir.

Paketi de kısaca açıklamak gerekirse, SQL Server çalıştıran ve bölümlenmiş veri tabanı görünümleriyle MSCS kullanan veri tabanı sunucuları bunlara örnektir. Bu durumda, paketin üyeleri verilere iletişimi paylaşır ve tüm istekleri işlemek yerine, verilerin ya da mantığın belirli bir bölümünü işlerler. Örneğin iki adet Node barındıran SQL Server cluster yapısında, bir sunucu A-M harfleri ile başlayan diğer sunucu ise N-Z harfleri ile başlayan hesapları işliyor olabilir.

Cluster mimarisi kullanan sunucular genelde üç katmanlı bir yapı kullanılarak tasarlanır bu yapı bahsettiğimiz şekilde,

Katman1- NLB’nin kullanıldığı ön uç Web sunucuları

Katman2- CLB’nin kullanıldığı çeşitli Uygulama sunucularını içeren orta katman sunucuları

Katman3- MSCS’nin kullanıldığı arka uçta yer alan veri tabanı sunucularını ya da dosya, kritik destek alanında görev yapan sunucuları içerir.

Cluster yapısı hazırlanırken bu şekildeki katmanlı bir yapı izlenmesinin asıl nedeni, cluster yapmanın asıl amaçlarından biri olan ölçeklenebilirliktir(scalability). Bu ölçeklenebilirlik istenilen katmana yeni sunucular ekleyerek ölçeğin artırılmasıyla gerçekleşebilir. Burada kritik nokta kullanılan sunucu işletim sistemidir.

· Windows Server 2003’ün tüm sürümleri, en fazla 32 Node’dan oluşan bir NLB Cluster destekler.

· Enterprise ve Datacenter Edition, en fazla 8 Node’lu bir CLB cluster destekler.

· Enterprise ve Datacenter Edition, en fazla 8 Node’lu bir MSCS cluster destekler.

İşlemci ya da RAM ekleyerek ölçek artırılmak isteniyor ise

· Standart Edition, en fazla 4 işlemci ile 32bit sistemlerde 4gb RAM ve 64bit sitemlerde 32gb RAM destekler

· Enterprise Edition, en fazla 8 işlemci ile 32bit sistemlerde 32gb RAM ve 64bit sitemlerde 64gb RAM destekler

· Datacenter Edition, en fazla 128 işlemci ile 32bit sistemlerde 64gb RAM ve 64bit sitemlerde 512gb RAM destekler

Ölçeklenebilirlik gereksinimleri belirlenirken kuruluşun “live” sitemdeki ve piyasadaki ileriye dönük gereksinimleri göz önünde bulundurulmalıdır. Doğru Windows sürümü ile uygun ölçeklenebilirlik sağlanabilir. Buna ek olarak, işlemciler ve bellek (RAM), sunucuların çalıştıracağı uygulama ve hizmetlerin yanı sıra, eş zamanlı olarak gerçekleştirilecek kullanıcı bağlantı sayısına uygun olarak boyutlandırılmalıdır. Eş zamanlı kullanıcı sayısı özellikle WebFarm senaryosunda dikkat edilmesi gereken önemli bir noktadır.

Bir sonraki bölümde NLB hakkında genel açıklamalar ile WebFarm senaryosu için yapılandırılmasını ve uygulanmasını anlatacağım.

KAYNAK:

-Microsoft/Technet

-Server2003 Inside/Out –William R. Stanek

Ahmet TOPRAKÇI
BilgeAdam IT Academy
System & Network | Beşiktaş

Microsoft’un daha az kaynak tüketen, aynı zamanda maliyet açısından daha uygun olan Windows Server 2008 işletim sisteminin Core sürümü, kullanımı biraz zahmetli olsa da oldukça başarılı hizmetler sunmakta. Bu çekirdek hizmetlerden biri olan DNS servisinin, yazımızın sonunda da görüleceği gibi bir hayli kullanışlı olduğu anlaşılıyor.

Bu makalede Dns servisinin Windows Server 2008 Core sürümü üzerine kurulumu ve konfigürasyonu anlatmaya çalışacağım. Dilerseniz hemen kurulum işlemine geçelim…

Windows Server 2008 işletim sisteminde herhangi bir servis için kurulum diskine ihtiyaç bulunmadığından direkt olarak command-line arayüzünden kurulumu başlatabiliriz. Dns kurulumu için gerekli olan ip konfigürasyonunu yapmakla başlayalım. Bunun için netsh komutunu Resim 1’deki parametreler yardımı ile kullanacağız.

Resim 1

İlk komutu network interface’lerin id’lerini görmek için, ikinci komutu statik ip adresi vermek için, ve son komutu da dns server olarak kendi server’ımızı tanımlamak için kullanıyoruz. Komutlar hakkında ayrıntılı bilgi için http://www.sistemuzmani.com/Articles/Details.aspx?aId=1000001181 adresindeki makaleyi inceleyebilirsiniz.

Resim 2

Ip Konfigürasyonumuzu tamamladıktan sonra dns kurulum işlemine başlayabilriz. Bunun için Resim 2’de görüldüğü gibi start /w ocsetup DNS-Server-Core-Role komutu kullanacağız. Burada Start komutu Windows bileşenlerini kurmak için kullanılan ocsetup komutunu çalıştırmak için kullandık. /w parametresi kurulumun bitimine kadar bir başka işlem yapamamamıza neden oluyor. Eğer bu parametreyi kullanmasaydık kurulum arka planda gerçekleşecek ve o esnada başka işlemler de yapabilecek durumda olacaktık.

Burada önemli bir noktaya değinmek isterim; ocsetup komutu ile birlikte kurulması istenilen bileşenin adı tam ve büyük-küçük harflere dikkat edilerek yazılmalıdır. Dns servisi için bileşen ismi ise DNS-Server-Core-Role olmak durumundadır (Resim 2).

Resim 3

Kurulumdan hemen sonra servisimiz çalışmaya başlayacaktır. Dilerseniz Dns Servisinin çalıştığını teyit etmek için sc query dns komut ve parametrelerini kullanabiliriz (Resim 3).

Resim 4

Servisin kurulumunu gerçekleştirdikten sonra sorgulara yanıt vermek amacı ile kullanılacak kayıtların tutulacağı bir zone yaratma işlemine geçelim. Öncelikle, yetkili (Authoritative) bir dns server’ın tutması gereken zone tipini yani primary zone’u yaratalım. Bunun için dnscmd komutunu Resim 4’te görüldüğü şekilde kullanıyoruz. Burada /zoneadd parametresi yeni bir zone eklemek için, /primary parametresi anlaşılacağı üzere primary zone oluşturmak için, /file parametresi ise oluşturacağımız zone’un hangi isimde saklanacağını belirtmek için kullanılır. Oluşturacağımız zone’un ismi test.com ve saklayacağımız dosyanın ismi de test.zone.com olacaktır (Resim 4). /primary parametresi yerine /dsprimary parametresi kullanarak Active Directory Integrated Zone da oluşturabiliriz.

Resim 5

Primary zone yarattıktan sonra içeriğini notepad yardımı ile Resim 5’teki komutları yazarak görebiliriz. Henüz herhangi bir kayıt oluşturmadığımız için sadece SOA değerlerini ve NS kaydının var olduğunu görebiliyoruz.

Resim 6

Primary Zone içerisine yeni kayıtlar oluşturmak için dnscmd komutuna Resim 6’da görülen parametreleri ekleyerek çalıştırıyoruz. Buradaki /recordadd parametresi yeni bir kayıt eklemek için, A yardımcı parametresi bir Host kaydını oluşturmak için kullanılır. Oluşturacağımız bu yeni kaydın adını www ve ip adresini 10.4.10.121 olarak tanımlıyoruz.

Resim 7

Bir başka kayıt oluşturmak için Resim 7’deki komut ve parametrelerini kullanıyoruz. Bu defa oluşturacağımız kayıt bir ALIAS yani bir HOST kaydına verilen takma bir isim. Kullanılan yardımcı parametre ise adından da anlaşılacağı üzere CNAME olacaktır. Az önce oluşturduğumuz A kaydına (www) vereceğimiz yeni isim web olacaktır.

Resim 8

Benzer şekilde MX (Mail Exchanger) kaydını oluşturmak için Resim 8’de görülen komut ve parametrelerini kullanabiliriz. Burada farklı olarak 10 sayısını görmekteyiz ki bu sayı MX kaydının kullanım önceliğidir.

Resim 9

Oluşturduğumuz kayıtları yine dnscmd komutu ile görebiliriz. /enumrecord Parametresi isteğimize karşılık verecektir. Tabi hangi zone için ne tür bilgi istediğimizi de belirtmek şartıyla… Komutun sonuna koyduğumuz . (nokta) zone’a ait tüm kayıtların listelenmesini sağlayacaktır. (Resim 9).

Resim 10

Dilersek aynı bilgileri notepad yardımı ile zone dosyasını açarak da görebiliriz. Hatta buradan yeni kayıtlar da ekleme imkanımız bulunmaktadir (Resim 10)

Resim 11

Primary Zone için gerekli kayıtları da oluşturduktan sonra nslookup arayüzünü kullanarak Resim 11’deki testlerimizi yapabiliriz. Gayet başarılı görünüyor…

Resim 12

Oluşturduğumuz Primary Zone’un diğer DNS server’lar tarafından kopyalanabilir olmasını sağlamak için Zone Transferine izin vermemiz gereklidir. Bu işlemi Resim 12’de görülen komut ve parametreleri ile gerçekleştirebiliyoruz. /zoneresetsecondaries parametresi amacımıza ulaşmamazı sağlayan parametremizdir. /nonsecure parametresi ise isteyen her server’ın bu zone’dan bir kopya almasını sağlamak için kullanılır.

Resim 13

Tabi ki güvenliğin önemi nedeni ile her isteyen server’a bu hakkı vermek istemeyebilirsiniz. Bu işlemi belirli server’ların gerçekleştirmesini sağlamak için Resim 13’te görülen komut ve parametrelerini kullanmamız gerekecektir. /securelist parametresi ile ip adresini tanımladığımız server’a bu hakkı tanımış olacağız.

Resim 14

Zone’daki değişikliklerin algılanmasını sağlamak amacı ile Zone Transferine izin verdiğimiz server için uyarı verilmesini de Resim 14’de görülen komut ve parametre ile sağlayabiliyoruz. /notifylist parametresi ile ip adresini tanımladığımız server’a bu hakkı tanımış olacağız.

Resim 15

Primary Zone’dan sonra bir Primary Zone kopyası olan Seconrary Zone’u oluşturmak amacı ile Resim 15’te görülen komut ve parametrelerini kullanarak amacımıza ulaşabileceğiz. Buradaki /secondary parametresi ile adından da anlaşılacağı gibi oluşturmak istediğimiz Secondary zone için gerekli parametredir. Primary Zone’da olduğu gibi burada da bir zone ve bu zone için bir dosya ismi belirtmemiz gerekecektir. Primary Zone’dan farklı olarak Zone kopyasını almak istediğimiz Master Dns Server’ın ip adresini belirtmemiz gerekmektedir.

Resim 16

Secondary Zone’u oluşturduktan sonra Master Dns’ten Primary Zone’daki kayıtların kopyasını transfer etmek amacı ile Resim 16’da görülen komut ve parametrelerini kullanmamız gerekecektir. Buradaki gerekli parametremiz ise /zonereload parametresidir. Eğer sadece değişikliklerin transfer edilmesi istenirse /zonerefresh parametresi ile bu işlemi gerçekleştirebiliriz. Zone kayıtlarının trasfer olduğundan emin olmak için notepad editörünü veya dnscmd komutu ile /enumrecord parametresini kullanabiliriz.

Resim 17

Benzer şekilde Primary Zone’un kopyasını Stub Zone oluşturarak da alabiliriz. Bilindiği üzere Stub Zone ile birlikte gelen zone kayıtları Secondary Zone ile gelen kayıtlardan daha az olacaktır. Kullanım amacına göre Stub Zone tercih edilebilir. İşlemi gerçekleştirmek için kullanacağımız komut ve parametreleri Resim 17’deki gibi olacaktır. Secondary Zone oluşturmak için kullandığımız parametrelerden tek farkı /secondary yerine /stub parametresinin kullanılmasıdır.

Resim 18

Stub Zone’un kayıtlarını Resim 17’deki komut ve parametre ile görebiliriz. Sadece SOA ve NS kayıtları geldiğine göre Stub Zone oluşturma amacımıza ulaşmış sayılıyoruz.

Resim 19

Sıra geldi isim çözümleme servislerinin vazgeçilmezi olan Forwarder tanımlama işlemine. Herhangi bir domain için Zone barındırmak istenmiyorsa Resim 19’da görülen komut ve parametreleri kullanılarak Forwarder tanımlanabilir. Her ne kadar bir Zone’a benzemese de /zoneadd parametresi ile bu işlemi gerçekleştirmek durumundayız. Gerekli diğer parametre ise /forwarder parametresidir. Tabi ki hangi dns domaini için hangi ip adresine yönlendirme yapılacağını da belirtmek durumundayız. Bu tür forwarder’ların Conditional (Koşullu) Forwarder olarak adlandırıldığını hatırlattıktan sonra test işlemine geçebiliriz.

Resim 20

Basit olarak tanımladığımız domain için ping komutunu kullanarak Dns servisimizin yönlendirme yaptığını teyit edebiliriz (Resim 20).

Resim 21

Az önce belirttiğimiz gibi Conditional Forwarder sadece bir domain için belirtebileceğimiz bir yönlendirme türüdür. Dns Server’ımızın internetteki tüm domain’ler için gerekli çözümleyi yapması istenirse Traditional (Geleneksel) Forwarder kullanmamız gerekecektir. Bu forwarder sayesinde Dns Server’ımızın çözemediği her türlü sorgu istenilen adrese yönlendirilecektir. Örneğin ISP Dns server ip adresine… Resim 21’de Traditional Forwarder’ı oluşturmak için gerekli komut ve parametreleri görülmektedir.

Resim 22

Resim 22’de ismini lokal olarak çözemeyeceğimiz bir domain’in çözümleme testini basitçe ping komutu ile başarmış bulunuyoruz.

Görüldüğü üzere Windows Server 2008 Core sürümü üzerinde DNS konfigürasyonu oldukça kolay olmakla birlikte çoğu zaman keyifli bile olabilmektedir. Daha az kaynak ve maliyet ile ihtiyaç duyduğumuz servislerin konfigürasyonu için zaman harcamaya değer olduğu, sanıyorum Microsoft’u doğrulamaktadır.

Bir başka makalede görüşmek dileği ile…

Seymen URAL

Kaynak: Microsoft Technet

Microsoft sizlere bilgisyarınızın Vistaya uyumlu olup olmadığını kontrol etmek için bir program sundu. Bu programın adı Vista Yükseltme Danışmanı.

Bu programın kullanımını resimlerle anlattık.

:: Resimli anlatıma ulaşmak için tıklayın

Vista yükseltme danışmanını indirmek için tıklayın

ICMP Ufak bir bilgi var üst tarafta..biz bunu biraz daha açalım inceleyelim..

Echo: Echo mesajları, bir yönlendirici veya host tarafından diğer bir yönlendirici veya hosta gönderilen mesajlardır. Echo mesajı kaynaktan hedefe yönelen bir mesaj olup, tepki mesaj olarak hedeften kaynağa Echo Reply (Echo Cevabı) mesajı döner. Echo mesajı ile hedef hostun çalışıp çalışmadığı ve iletişim kurmak için gerekli yolun sağlanıp sağlanamayacağının testi yapılır. TCP / IP protokol grubu yüklü olan hostlar üzerinde çalıştırılan PING komutu bu işlevi yerine getirir.
destination unreachableFragment gerektiğinde DF’nin değeri 1 ise bu mesaj oluşur.
source quench: datagramların geçiş oranını kontrol eder. Bu mesaj alınınca gönderim hızı azaltılmalıdır.
redirect: Daha iyi bir rota mevcut olduğu durumlarda gatewaye gönderilir. Bu mesaj gönderilince code fieldde oluşan oluşan numara routing durumlarını belirler.
parameter problem: semantic veya synatatic hata oluştuğunda açığa çıkar. Genelde optionslarda kullanılan hatalıargümanlar buna sebep olur.
echo request veya reply: Debugging için kullanılır.
timestamp request ve reply : networkten geçen mesajın süresinin gözlenmesini sağlar.
information request ve reply, address mask request ve reply: Özel network veya subnetworkün denenmesi için.

StickyPad önemsiz notlarınızı masaüstüne yapıştırıp unutmanızı engelleyen bir yazılımdır. Kendi kendinize notlar alabilir, toplantılarınızı, hatırlatmalarınızı ya da yapacaklar listenizi böylelikle sürekli gözünüzün önünde tutarsınız. Aldığınız bu notlar yazıcıdan çıktı olarak alınabilir, diğer uygulamalar üzerinde kullanılabilir veya arkadaşlarınıza e-posta ile gönderilebilir.

Aldığınız notları geçirgen bir çerveye oturtarak kendi işlerinizle ilgilenirgen bir yandanda notlarınızı inceleyebilirsiniz. Bilgisayarda oturumu kapattığınızda StickyPad bilgileri belleğinde tutar ve tekrar oturum açtığında işine kaldığı yerden devam eder. Bir kere denedikten sonra StickyPad olmadan randevularınızı organize edemez olacaksınız.

   İndirmek İçin:

http://rapidshare.com/files/68263816/Install_StickyPad.zip

IEEE 802.11x

IEEE tarafından geliştirilen ve en yaygın standartlardan biri durumuna gelen 802.11x biw WLAN standartıdır.hernekadarda kablosuz bir yapıya sahip olmuş olsa bile terminallerin uç noktalarında kullanılan fiziksel cihazlardan dolayı bir çok özelliği 802.3 ethernet standartlarına benzer

-MAC
-Sinyalleşme teknikleri ve arayüzleri
-Security

TCP/IP UYGULAMALARI

LLC 802.2

MAC 802.11

802.11

ıRda
802.11

FHSS
802.11

DSSS
802.11a

OFDM
802.11b

DSSS
802.11g

OFDM

Görüldüğü üzre LLC gibi mantıksal bir link control sistemi ile üst katmanlarla sorunsuz çalışması sağlanmıştır.LLC katmanı TCP/IP yönlendirme işlemlerinde tüm arayüzler için uyumluluk sağlayabilecek bir yapıya sahiptir.MAC 802.3 de olduğu gibi verinin üst katmanlara düzgün bir şekilde iletilimesini sağlar.
802.3 de olduğu gibi 48 bitlik bir yapıya sahiptir ve aynı özellikleri üslenir.

Ethernet ağlarda olduğu gibi kablosus ağlardada birden fazla terminal aynı anda aynı iletişim ortamını kullanmak isteyebilir. Bu durumda diğer yapıda olduğu gibi çarpışma(collision) oluşacaktır.yine kablosus yapılardada 2. katman bir collision detection a benzer collision avoidance denilen (CSMA/CA) bir çarpışma tespit ve önleme algoritması kullanılmaktadır.(bkz MY 2.katman cihazlar Switchler-kim kaparsa onundur :-)).

802.11x için Fiziksel Katman

genel olarak hava taşıma ortamı ile mac arasındaki arayüzün adıdır.802.11x de birden fazla fiziksel arayüz mevcuttur. Nedeni ise taşıyıcı frekans ve çoklama yöntemlerinden kaynaklanmaktadır. Yani taşıyıcı frekansız yada çoklama yöntemini değişmesi fiziksel yapının değişmesine neden olabilir(dolayısıyla standartın).
802.11 standartı 1997 yılında IEEE tarafından tescil edilmiş ve yayınlanmıştır.

802.11a
OFDM denilen bir sinyali birden çok sinyale bölerek her bir sinyali farklı bir taşıyıcı ile iletilmesini sağlayan bir teknikle kullanılmış olup 5 Ghz UNII bandında çalışan bu yapı 54 mbps lik bir taşıma hızına sahiptir.
802.11a için 12 adet radio kanalı mevcuttur ancak kanallar mantıksal olarak üst üste bineceğinden(chanel overlapping) maksimum 8 kanal terminallere aynı anda hizmet verebilmektedir.

802.11b
DSSS denilen özel bir spectrum sayesinde sinyalleri küçük parçalara bölüp kodlanarak gönderilmesini sağlar.2.4 ISM bandını kullanır. Taşıma kapasitesi 11 mbps dir. 11 adet kanal tanımlanmıştır üst üste binmeyen yani aynı anda hizmet verebilen kanal sayısı 3 dür.

802.11g
OFDM tekniğini kullanır.2.4 ISM bandına çalışır.54 mbps taşıma kapasitesine sahiptir.

Özetle 802.11a ile 802.11g farklı frekans kullanmalarına rağmen taşıma kapasiteleri aynıdır. Bunun nedeni ise kullandıkları OFDM tekniğidir.her nekadarda aynı tekniği kullanmış olsalar dahi farklı frekanslarda olması itibariyle fiziksel yapıları birbirlerini desteklemez ve aynı ortamda birlikte çalışamazlar.
802.11b ile 802.11g aynı frekansta çalıştıkları için donanımsal yapıları birbirlerini destekler.

802.11a
OFDM
5 Ghz
54 Mbps

802.11b
DSSS
2.4 Ghz
11 Mbps

802.11g
OFDM
2.4 Ghz
54 Mbps

X25