Baglantilar

Yazar: | Kategori: Genel
Yorum: 2

SQL Server 2000 hem uygulama geliştiriciler, hem de firmalar açısından çok önemli kazanımlar sağlayan, rdbms alanında dönüm noktası olarak kabul edebileceğimiz bir ürün olarak hayatımızda varoldu.. Açıksözlü olmak gerekirse 27 Ekim 2005 tarihinde MSDN Subscriber’lara RTM’i dağıtılmaya başlanan SQL Server 2005 ürününü incelediğimizde, SQL Server 2000’den 2005’e geçişin çok hızlı olacağını düşünmüyorum. Ancak ürünü detaylı olarak inceledikçe, SQL Server 2005’in uzun vadede Microsoft’un rdbms alanında liderliğini perçinleyecek bir ürün olacağı yönündeki düşünceme katılıyor olacağınızdan eminim. SQL Server 2005’in uygulama geliştirme alanında bize sunduğu artıları ele almadan önce altyapıda ne gibi değişikliklerin ve yeniliklerin olduğunu ele almakta fayda görüyorum. Dolayısıyla bu dokumanda SQL Server 2005 ile birlikte veritabanı yönetimi alanında gelen yenilikleri veritabanı mimarisi ve sotorage engine, veritabanı yönetim ve geliştirme araçları ve süreklilik ve veri güvenliği şeklinde üç ana başlık altında ele alıyor olacağız.

Veritabanı Mimarisi ve Storage Engine
Microsoft SQL Server 7 ile geliştirdiği mimariyi sürekli olarak geliştirdi. Hepimizin bildiği ve doğruluğunu kabul ettiği kurala göre mevcut donanımların maliyeti düşerken, gücü ise her 18 ayda öncekine göre iki katına çıkıyor. SQL Server 2005 ile birlikte Microsoft’un öncelikli hedeflerinden biri, veritabanı motorunun mevcut donanım altyapısından ve geliştirilen Windows Server 2003 (ve sonrasında gelecek olan) işletim sisteminden mümkün olan en fazla oranda faydalanmasını sağlamak. SQL Server 2005 ile birlikte gelen yeni özellikler ve güncellemelerin diğer hedefleri ise kurumlar açısından yönetimi daha kolay ve şirkete daha çok değer katan bir veritabanı motoru oluşturmak. Bu bölümde SQL Server 2005 ile birlikte SQL Server mimarisindeki yenilik ve gelişmeleri, kurumumuza ve iş süreçlerimize ne gibi artılar katabileceklerini de ele alarak inceliyor olacağız.

Donanım Desteği
Donanım alanındaki gelişmeler ve hızla daha düşük seviyelere inan donanım maliyetleri, firmaların daha güçlü bilgisayar sistemlerine çok daha düşük maliyetlerle sahip olabilmesini mümkün kıldı. Özellikle sunucu alanında 32-bit sistemlerde yaşadığımız gelişmeler ve hızla yaygınlaşmaya başlayan ve donanım alanında bir dönüm noktası olarak nitelendirebileceğimiz 64-bit sistemler, donanım alanındaki sorunlarımızın neredeyse tamamını ortadan kaldırdı. Bellek, veritabanı performansında her zaman için en kritik unsurlardan biri olmuştur. 54-Bit platformunda UNIX tabanlı sistemler, non-clustered TPC-C performans testlerinde uzun süre liderliği elinde bulundurdu. Ancak SQL Server 2005, ilk 64-Bitlik sürümünde liderliği devraldı. Performans testlerine baktığımızda, 64-Bit SQL Server 2005’in, 64-Bit Windows Server 2003 üzerinde, Intel Itanium platformunda gerçekten çok çok başarılı sonuçlar sergilediğini görüyoruz.

64-Bit Desteği
SQL Server 2005, Windows Server 2003 for 64-Bit Itanium systems üzerinde Intel Itanium ve Itanium2 mikroişlemcilerini desteklemektedir. Windows Server 2003 for 64-Bit Extended Systems üzerinde ise AMD’nin 64-Bit Opteron platformunu ve Intel’in “Xeon with Intel Extended Memory 64 technology (EMT64” sistemlerini de desteklemektedir. SQL Server 2005, tüm ana bileşenleri (SQL Server Engine, Analysis Services, SQL Agent ve Reporting Services) için hem 32, hem 64-Bit platformları desteklemektedir. Veritabanı altyapımızı 64-Bit platformuna taşımanın bize sağlayacağı en önemli kazanım her ne kadar daha yüksek işlem gücü olarak görünse de gerçekte en önemli kazanım: artan adreslenebilir bellek oranıdır. Şekil 1:1’de SQL Server 2005’in 32-Bitlik ve 64-Bitlik sürümleri tarafından adreslenebilen bellek miktarlarının karşılaştırmasını görebilirsiniz.


Şekil 1:1 :: 32-Bit ve 64-Bit SQL Server 2005’in Bellek Adresleme Oranları

32-Bit mimarisi en fazla 4GB bellek adresleyebilmektedir. Windows altında bu oran işletim sistemi ve uygulamalar arasında paylaştırılır. Diğer bir deyişle 2GB işletim sistemi için rezerve edilirken kalan 2GB uygulamaların kullanımına tahsis edilmektedir. 32-Bit Windows üzerinde yer alan Advanced Windowing Extensions (AWE) desteğini kullanarak, 32-Bit SQL Server’ın 32GB’a kadar bellek adresleyebilmesini sağlayabilmekteyiz. Her ne kadar bahsettiğimiz artış yeterli gibi görünebilse de, yönetilebilen bellek sayfalarındaki limit değişmiş olmuyor. 64-Bit Platformu adreslenebilen bellek miktarını 32TB’a çekerek bu konudaki sıkıntıları uzun bir süre için ortadan kaldırıyor. Şu anda neredeyse hiç bir yerde bu oranda bellek kullanılmıyor olsa da, SQL Server 2005’in test edildiği en yüksek bellek miktarı 512GB’dır. Windows Server 2003 için gelecek bir sonraki Service Pack ile birlikte desteklenen en yüksek bellek miktarının 1TB’a çıkartılması hedefleniyor.

NUMA (Non-Uniform Memory Architecture) Desteği
Windows Server 2003’ü üstün kılan yeni özelliklerden biride Non-Uniform Memory Architecture (NUMA) desteğidir. NUMA, IBM ve Unisys gibi bazı sistem üreticileri tarafından kullanılan ve çok işlemcili sistemlerde işlemci ve bellek kullanımını SMP (Symmetric Multiprocessing) mimarisine göre çok daha etkin bir şekilde yöneten bir mimaridir. Standart SMP sistemlerde işlemcilerin hızı ve sayısı arttıkça, işlemciler arasında belleğe erişme amaçlı yaşanan rekabet gereksiz yoğunluğa neden olur. Bu da doğal olarak bazı gecikmelere neden olur. Bunun sonucunda SMP sistemler işlemci sayısının artışıyor orantılı olarak esneklik gösteremezler. NUMA mimarisi SMP sistemlerde yaşanan bu sorunları, işlemcilerin RAM üzerindeki verilere, RAM ve BUS’ın sağlayabileceğinden çok daha hızlı olarak erişmesine olanak tanıyarak ortadan kaldırmak amacıyla tasarlanmıştır. NUMA mimarisi işlemci ve belleği çoklu işlemcilerden oluşan yerel gruplara ayırır. Bu gruplar birbirlerine, gruplar arası veri trafiğinin aktarıldığı harici bus’lar ile bağlıdır. Bu grup sıralama mimarisi, belleğe erişmek için yarışacak işlemcilerin sayısını limitleyerek SMP sistemlerde yaşanan işlemciler arası rekabetin önünü kesmektedir. NUMA mimarisinin artılarından en fazla oranda faydalanmak için hem işletim sistemi, hem de uygulamalar gruplar arası veri trafiğini en aza indirgeyecek ve grup içi erişimi arttıracak, hızlandıracak şekilde tasarlanmalıdır. Eğer işletim sistemi ve uygulama doğru olarak tasarlanırsa, NUMA mimarisi işlemci sayısının artışına orantılı olarak esneklik sağlayacaktır. Windows Server 2003 ve SQL Server 2005 mimari gelişmeleri bünyelerinde birleştirerek işlemci ve bellekten en yüksek oranda faydalanmamızı sağlayacak şekilde tasarlanmışlardır.

Hyper-Threading Desteği
SQL Server 2005 aynı zamanda Microsoft’un Windows Server 2003’e eklediği hyper-threading desteği ile hyper-threading’in sunduğu avantajlardan da faydalanabilmektedir. Hyper-Threading, Intel tarafından geliştirilen ve sistem üzerindeki her bir fiziksel işlemci için iki mantıksal işlemci oluşturan bir teknolojidir. Her bir mantıksal işlemci eşzamanlı olarak farklı thread’leri işleyebilme yeteneğine sahiptir. Hyper-Threading’in asıl hedefi multithreading uygulanmış uygulamalarda veya aynı makina üzerinde çalışan birden çok sayıda uygulamaya daha iyi kaynak ayrımının daha verimli yapılmasını sağlamaktır.

SQL Server 2005, Windows Server 2003’ün Hyper-Threading desteğinden iki şekilde faydalanmaktadır. İlk olarak, Windows 2000’in aksine, Windows Server 2003 fiziksel işlemcileri sadece lisanslama amacıyla saymaktadır. Boylece hyper-threading kullanan bir işlemci, iki yerine bir işlemci olarak sayılıyor. Windows Server 2003, hyper-threading kullanan sistemlere yönelik gelişmiş thread scheduling desteği sunmaktadır. Bu değişiklikler SQL Server gibi multithread uygulamalarda çok daha iyi performans sonuçları alabilmemizi sağlıyor.

SQL Server Engine
İlk bölümde SQL Server 2005 ile gelen donanım desteğine biraz daha geniş açıdan baktık. Bu bölümde ise SQL Server veritabanı motorundaki yeniliklere daha detaylı bakıyor olacağız.

.NET Framework Entegrasyonu
SQL Server 2005 ile birlikte gelen en önemli yeniliklerin başında Microsoft .NET Framework entegrasyonu ve sağladığı avantajlar geliyor diyebiliriz. .NET Framework entegrasyonu SQL Server 2005’in esnekliğini stored procedure, user-defined function, trigger, aggregate ve user-defined type’ların, visual basic, c# veya j# gibi bir .NET dili ile geliştirilmesini mümkün kılarak arttırmaktadır. Sonraki bölümlerde bu entegasyonun çok daha derin ve detaylı olduğunu göreceğiz.

Geliştirilmiş Çoklu Instance Desteği
SQL Server 2005 Enterprise Edition’da bulunan bir diğer yenilik ise aynı anda çalıştırılabilecek instance sayısının 50’ye kadar arttırılabiliyor olması. SQL Server 2000’de eşzamanlı instance desteği 16 ile sınırlıydı.

Yeni Veri Türleri
SQL Server 2005 pek çok yeni veri türünü desteklemektedir. .NET Framework entegrasyonu kullanıcı tanımlı türlerin geliştirilmesini sağlarken, varbinary(max) ve XML türünde yeni veri türlerini de desteklemektedir. Varbinary(max) beri türü SQL Server’da LOB’ların kullanımı için yeni bir metod sunmaktadır. Image ve Text veri türlerinin aksine varbinary(max) veri türü bir değişken olarak kullanılabilir ve daha kolay ve tutarlı işlem yapmak için daha küçük veri türleri gibi işlem yapılabilir.

Yeni XML veri türü varbinary(max) veri türüne dayanmaktadır ve XML dokumanlarını veritabanında saklamamıza imkan verir. XML veri türü, XML formatındaki verilerin hızlı ve kolayca saklanması ve kullanılmasını sağlamak amacıyla geliştirilmiş ve XML dokumanlarının schema ile doğrulanmasına olanak vermektedir. SQL Server 2005’te yer alan XML ve diğer veri türlerini ileriki bölümlerde ele alıyor olacağız.

Database Snapshot’ları ve Mirroring
Database Mirroring veritabanı seviyesinde sunulan ve sürekliliği arttırmak, sağlamak için SQL Server 2005 tarafından desteklenen tüm donanımlar ile uyumlu çalışan bir özelliktir. Database Mirroring için primary server ve mirrored server arasında bir paylaşıma gereksinim ve herhangi bir uzaklık limiti bulunmamaktadır. Database Mirroring, transaction log’larını primary ve mirrored sunucu arasında ileterek çalışmaktadır, bu yapısından dolayı Database Mirroring özelliğini gerçek-zamanlı bir log-shipping uygulaması olarak kabul edebiliriz. Database Mirroring tek bir veritabanı ile kullanılabileceği gibi, çok sayıda veritabanı ile de kullanılabilir.

Database Snapshot’ları veritabanının istenilen bir anına yönelik read-only fotoğrafını verirler. Database Snapshot’ları raporlama amaçlı bir veritabanının istenilen zamana ait bir kopyasını oluşturmak veya istenilen zamanda roll-back yapmak için belirli bir anda yedek almak amaçlı kullanılabilirler. Database Snapshot’ları, Database Mirroring ile bir arada kullanılarak mirrored server üzerindeki verilere dayanan bir reporting server oluşturmak için kullanabilmekteyiz. Mirrored sunucu üzerindeki veri, bu sunucunun her zaman recovery mode’da olmasından dolayı doğrudan erişşilebilir değildir ancak Mirrored database üzerinde bir Database Snapshot yaratarak bu verileri (read-only olarak) raporlama amacıyla kullanabiliriz.

Native HTTP Desteği
SQL Server 2005 ile birlikte gelen en önemli yeniliklerden biri de SQL Server Engine’e eklenen native HTTP desteğidir. SQL Server’ın gelen HTTP taleplerini işleyebilmesi, SQL Server’a stored procedure’leri ve SQL ifadelerini SOAP protokolünü kullanarak çalıştırabilmesi anlamına geliyor. Bu aynı zamanda SQL Server 2005’in, IIS olmadan web servis taleplerini karşılayabilmesi anlamına geliyor. SQL Server aynı zamanda endpointler için web servislerini WSDL olarak yayınlama yeteneğine sahiptir. SQL Server’ın HTTP özelliği hem Windows hem de SQL Server authentication’ı, SSL ile birlikte desteklemektedir. Bu özelliğin artılarını özellikle uygulama geliştiriciler için daha da arttırmak için stored procedure’ler sonuç kümelerini ADO.NET dataset’leri olarak döndürebilme imkanını sunmaktadır.

Sunucu Olayları ve DDL Trigger’ları
SQL Server 2005 ile birlikte gelen Sunucu Olay ve Trigger özellikleri, sistemdeki değişikliklere karşı nasıl karşılık verileceğini programatik olarak belirlememizi mümkün kılmaktadır. Bu iki özellikte benzer işler yapıyor gibi görünse de, sunucu tarafında işlemleri farklı şekillerde gerçekleştiriyorlar. Standart DML trigger’larında olduğu gibi, DDL trigger’ları da stored procedure’leri çalıştıran senkronize olaylardır.

Sunucu olayları ise asenkrondur. Sunucu olay modelinde sunucu SQL Server Broker Service’e bir olay gönderir. Olayla ilgilenen bu olaya sonradan bağımsız olarak erişebilir. Olay XML formatında kaydedilir. Bir olayı geri alma imkanı yoktur ancak kimsenin o olaya erişmemesi durumunda ignore edilir. Olay gerçekleştiğinde sizi olayın veya opsiyonel olarak bir kodun çalıştırıldığından haberdar edebilecek sistem olayı tetiklenir. Aşağıdaki kod bir event notification oluşturulurken kullanılacak söz dizimini örneklemektedir:

CREATE EVENT NOTIFICATION MyDDLEvents

ON SERVER FOR DDL_STATEMENTS TO SERVICE MyDDL_log

Bu kod yeni bir event oluşturup “MyDDLEvents” şeklinde isimlendiriyor daha sonra oluşturduğu olayı DDL statement ile ilişkilendiriyor. TO SERVICE ifadesi MYDLL_log adlı SQL Server Broker Servisinin bu olayın alıcısı olduğunu belirtiyor. SQL Server Broker Servisini ilerleyen bölümlerde detaylı olarak ele alıyor olacağız.

Veritabanı Veri Dosyasındaki Yenilikler
SQL Server 2005, ALTER DATABASE komutu aracılığıyla veritabanının log ve veri dosyasının yerlerini değiştirme imkanı sunuyor. SQL Server 2000 tempdb veritabanı için dosyalarını taşımaya izin veriyordu ancak diğer veritabanları için izin verilmiyordu. Tahmin edebileceğiniz üzere SQL Server 2005 dosyaların taşınmasını sadece offline bir işlem olarak mümkün kılıyor. Aşağıdaki örnek, veritabanı dosyalarının yerini değiştirmeyi sağlayan ALTER DATABASE komutunun sözdizimini göstermektedir:

ALTER DATABASE <database_name>

MODIFY FILE(name=<‘veri_dosyasinin_adi’>, filename=<‘yeni_veritabani_dosyasi_yolu’>)

Data Partitioning
SQL Server 2005’te yer alan bir diğer özellikse veri bölümlendirmedir. Veri bölümlendirme tablo veya index gibi tek bir veritabanı nesnesini birden çok bölüme ayırma imkanı vermektedir. Veri bölümlendirme özelliğinin öncelikli hedefi, çok büyük tablo ve indexleri yönetmeyi daha kolay hale getirmektir. Bölümlendirme, uygulamalar tarafından algılanamamaktadır. Uygulama çalışırken sadece tek bir tablo görmekte ve SQL Server tarafından yönetilen alt bölümlerden asla haberdar olmamaktadır. Bölümler, veritabanının sürekliliğini etkilemeden oluşturulabilir ve silinebilirler. Ek olarak partitioning verileri, bir uygulama tarafından kullanılırken dahi uygulamayı etkilemeden bölümlendirmenize olanak tanımaktadır. Şekil 1.1 bölümlendirmenin yapısını basitçe örneklemektedir.
Şekil 1.1 :: Veri Bölümlendirme

SQL Server 2005 tablolar, indexler ve indexlenmiş view’lar için veri bölümlendirmeyi desteklemektedir. Satır, veri bölümlendirmenin en temel elemanıdır. Bölümler, satırların alanlarında bulunan değerlere göre oluşturulabilir. Bu işlem, horizontal partitioning olarak adlandırılmaktadır. Örneğin bir tablo, her yıl için bir bölüm olacak şekilde tarihe göre bölümlendirilebilir.

Veri bölümlendirme çok büyük veritabanlarında (Very Large Databases – VLDBs) bazı önemli avantajlar sağlamaktadır. Veri bölümlendirme, verilerin yönetimini kolaylaştırmaktadır. Örneğin tarihe göre bölümlendirilmiş büyük bir tabloda önceki yılları hariç tutarak sadece bu yılın yedeğini almak isteyebilirsiniz. Bir diğer avantaj ise çok işlemcili sistemlerde daha yüksek performans için hangi bölümün, hangi işlemci tarafından işleneceğini belirtebilirsiniz.

Veri bölümlendirmeyi gerçekleştirmek için atmamız gereken iki basit adım vardır. İlk olarak hangi nesneyi, ne şekilde bölümlendireceğimizi belirlememiz gerekir. İkinci olarak her bir bölüm için fiziksel bir depolama lokasyonu belirtmemiz gerekir. Farklı bölümler, tek bir dosya grubuna atanabilir veya farklı dosya grupları tanımlanabilir.

Aşağıdaki örnek basit bir partition function oluşturmayı ve tabloyu bir Range Partition kullanarak bölümlendirmek üzere planlamayı örneklemektedir:

CREATE PARTITION FUNCTION MyPF

(int) AS RANGE LEFT FOR VALUES (50, 100)

GO

CREATE PARTITION SCHEME MyPS

AS PARTITION MyPF TO (FileGroup1)

GO

CREATE TABLE MyTable (col1 int, col2 varchar(50))

ON MyPS(col1)

GO

İlk satır MyPF adlı bir partition oluşturuyor. int, bölümlendirmenin int türünde tanımlanmış bir sütuna göre yapılacağını belirtiyor. RANGE keyword’u Range bölümlendirmenin uygulanacağını belirtiyor. LEFT keyword’u kesin olmayan değerlerin hangi partition’da saklanacağını belirtiyor. VALUES ifadesi bölümler için sınır değerleri belirtmek için kullanılıyor. Bu değerlerin sınır değerleri olduğunu ve bölümlendirilmediklerini unutmamakta fayda var. Bu komut 3 bölümün oluşması ile sonuçlanacaktır. İlk bölüm negatif değerleri ve 50’ye kadar olan pozitif değerleri, ikinci bölüm 51 ile 100 arasındaki değerleri, üçüncü bölüm ise 101’den büyük değerleri içerecektir.

İkinci satır, MyPS adlı bir bölüm şeması oluşturuyor. AS PARTITION ifadesi ise bu şema tarafından kullanılacak olan bölüm fonksiyonunu belirtmekte kullanılıyor. Bu örnek MyPF adlı bölüm fonksiyonunu kullanıyor. TO ifadesi bölümlerin kaydedileceği dosya grubunu veya gruplarını belirtmekte kullanılıyor. Bu örnek FileGroup1 adlı tek bir dosya grubunu kullanıyor.

Daha sonra, bölüm şemasının bölümlendirilecek tablo ile ilişkilendirilmeis gerekiyor. Bu örnek tablonun bölümlendirilmesine olanak tanıyan extended CREATE TABLE sözdizimini göstermektedir. CREATE TABL ifadesinin ilk bölümü aynı. Tablo adını (bu örnekte MyTable) ve sütunları belirtiyor. Örnek tablomuz col1 ve col2 adlı iki sütun içeriyor. Yeni gelen ON keywordu kullanılacak bölüm şemasını belirtmekte kullanılıyor. Bu örnekte az önce oluşturduğumuz MyPS şeması kullanılıyor. Bölümlendirme’de kullanılacak verileri içeren sütun parantez içinde yazılıyor. Bu örnekte kullandığımız sütun: col1. col1 sütununun veri türü int türünde. Seçilen sütunun veri türü, bölümlendirme fonksiyonunda belirtilen veri türü ile aynı olmalıdır.

Bölümlendirmede kullanılacak sütunların sahip olabileceği veri türleri konusunda bazı kısıtlamalar söz konusudur. Bu kısıtlamalar, index tanımlarken söz konusu kısıtlamalara oldukça benzemektedir. Text, ntext ve image veri türleri kullanılamıyor. Aynı şekilde timestamp sütunlarda partitioning key olarak belirtilemiyor. Sadece native T-SQL veri türleri partitioning key tanımlamalarında kullanılabilmektedir. Her bir tablo için 1000 bölüm üst sınırı ve tüm bölümlerin tek bir node üzerinde bulunması zorunluluğu mevcuttur.

Index Alanındaki Yenilikler
SQL Server 2005, indexlerde de pek çok yenilik getiriyor. İlk olarak, artık bir clustered index’in rebuild edilmesi, tüm non-clustered index’lerin rebuild edilmesini gerektirmiyor. SQL Server 2000’de, bir clustered index’i rebuild ettiğimiz zaman, tüm ilgili non-clustered index’ler de rebuild ediliyordu. SQL Server 2005, non-clustered index’lerin hasar görmesini engellediği için bu indexlerin rebuild edilmesi gerekmiyor.

İkinci olarak, yeni gelen “included columns” özelliği, non-key sütunların da bir index’e eklenmesine olanak tanıyor. Bu yeni özellik daha çok sorgunun index tarafından kapsanmasına ve böylece SQL Server Engine’in sorguyu tamamlamak için tabloya gitmesi ihtiyacını ortadan kaldırarak sorgu performansının ve hızının artmasına neden oluyor. Bu özelliğin en iyi yanlarından biride, index’e dahil edilen ve anahtarın bir bölümü olmayan sütunlar, hala 900 byte olan index üst sınırına dahil edilmiyor olması.

SQL Server 2005 ile gelen bir diğer yenilikse index’lerin disable edilebiliyor olması. Bir index’in disable edilmesi, bu index’in kullanılmasını ve SQL Server Engine tarafından işlemlerde dikkate alınmasını engelliyor. Bir index disable edildiğinde, SQL Server index için rezerve edilen alanı serbest bırakır ancak index’in metadata’sını saklar. Disable edilen index’in yeniden aktif duruma getirilebilmesi için, ALTER INDEX komutu ile rebuild edilmesi gerekir.

Online Index İşlemleri

SQL Server’ın önceki sürümleri, index’e rebuild sürecindeyken erişmeye imkan vermiyordu. Tablo’nun yeniden update edilebilir olması için rebuild sürecinin tamamlanmasını beklememiz gerekiyordu. SQL Server 2005’in online index işlemleri özelliği, uygulamaların index rebuild sürecindeyken, tablo üzerinde insert, update ve delete gibi işlemler yaparak index’e erişebilmelerine olanak tanıyor. Bu konuyu da ilerleyen bölümlerde detaylı olarak ele alıyor olacağız.

System Catalog ve Metadata Konularındaki Yenilikler
SQL Server 2000 ve daha önceki sürümlerde, sistem kataloğu ve metadata, master veritabanında her veritabanının bir parçası olarak saklanıyordu. SQL Server 2005 ile birlikte metadata sistem tarafından sys adında bir nesne olarak kaydedilen resource veritabanında saklanmaya başladı. SQL Server 2005 ile artık birlikte sistem veritabanlarına doğrudan erişemiyoruz. Bu değişiklik daha yüksek güvenlik ve daha hızlı sistem güncellemeleri sağlamak amacıyla getirildi. Catalog metadata’sının güvenliği row-level filtreler ile sağlanmıştır. SQL Server 2005’te Güvenlik alanındaki yenilik ve geliştirmeleri ilerleyen bölümlerde detaylı olarak ele alıyor olacağız.

Yeni metadata, Microsoft tarafından dokumante edilmemiş olan ve kullanılmaması konusunda uyarıda bulunduğu sistem tablolarını kullanmadığınız sürece tamamen backward compatible’dır. SQL Server 2005’te sistem metadatası, çeşitli catalog view’ları tarafından sunulmaktadır. Catalog view’ları, ANSI INFORMATION_SCHEMA view’ları, property fonksiyonları ve built-in fonksiyonlar ile birlikte, sistem veritabanı ve tablolarına doğrudan erişim ihtiyacını tamamen ortadan kaldırmaktadır. Toplamda 250nin üzerinde catalog view’ı bulunmaktadır ve bu view’lar her kullanıcı veritabanının sys şemasından görüntülenebilir. Yeni sistem view’larını Microsoft SQL Server Manager Studio’da, Object Browser’ı açarak, ilgili veritabanına -> views -> system views node’una giderek bulabilirsiniz. Aynı zamanda yeni bir sorgu ekranı açarak aşağıdaki kod ile de görüntüleyebilirsiniz.

select * from sys.system_views

Multiple Active Results Sets (MARS)

SQL Server’ın önceki sürümleri her bir bağlantıda sadece bir sonuç kümesini destekliyordu. SQL server 2005 tek bir bağlantıda birden çok sonuç kümesini destekliyor. Bu özellik, veritabanına tek bir bağlantı açarak bir sorgu çalıştırma, sonuç kümesi üzerinde çalışma, sonrasında bir başka sorgu daha çalıştırarak sonuç kümesi üzerinde çalışmaya devam edebilme imkanı sağlıyor. Bunun uygulamalar açısından sunduğu avantaj ise, uygulamanın oluşan sonuç kümelerinin tümüne erişebiliyor ve işlem yapabiliyor olmasıdır.

Bulk Data Loading
SQL Server 2005 bulk data loading özelliğinde, önemli bir performans artışı ile birlikte pek çok yenilik sunuyor. Bulk Data Loading özelliği artık XML tabanlı bir dosya kullanarak Bulk Copy programlarının format dosyasının sağladığı tüm özellikleri sunuyor. Ek olarak BCP’nin XML formatında işlem yapması, dosyaların daha kolay okunabilmesini ve anlaşılabilmesini sağlıyor. Önceki uygulamalar ile uyumluluğu sağlamak için eski BCP formatı halen desteklenmektedir.

SQL Server 2005’in bulk data loading prosesi artık hatalı satırların kaydını tutma özelliğini sağlamaktadır. Bu, yükleme işleminin hata ile karşılaşılması durumunda da devam edebilmesini sağlamaktadır. Hatalı olarak formatlanmış kayıtlar bir hata kayıt dosyasına kaydedilmektedir. Sınırlara uymayan satırlar ise hata durumuna bağlı olarak spesifik bir hata tablosuna yönlendirilirler.

Full-Text Search
SQL Server 2005’te Full-Text Search özelliği de geliştirilmiştir. SQL Server’ın Full-Text Search özelliği ile birlikte çalışabilmemiz için SQL Server 2005’e pek çok yeni DDL ifadesi eklenmiştir. Yeni DDL ifadelerine, CREATE FULLTEXT CATALOG ve CREATE FULLTEXT INDEX ifadelerini örnek olarak verebiliriz.

SQL Server 2005’te Full-Text Search özelliğinde gerçekleştirilen yenilikler, Full-Text Search kataloglarının ve indexlerin yedeklenebilmesi ve geri yüklenebilmesini, Full-text katalogların ilgili veritabanlarına attach ve detach edilebilmesini ve thesaurus kullanarak eş anlamlı kelimelerle yapılan aramaları bulma desteğini kapsamaktadır.

T-SQL Yenilikleri
SQL Server 2005 ile birlikte T-SQL’de de pek çok yenilik karşımıza çıkıyor. Bu yenilikler Common Table Expressions’ı, geliştirilmiş TOP ve WAITFOR ifadelerini, DML ifadeleri için OUTPUT ifadesini içermektedir. Bu yenilikleri ileriki aşamalarda SQL Server 2005’te T-SQL Alanındaki Yenilikler başlıklı bölümde detaylı olarak ele alıyor olacağız.

SQL Server 2005’te Güvenlik Alanındaki Yenilikler
Güvenlik Microsoft açısından her zaman en öncelikli konular arasında yer almıştır. Microsoft’un Trustworthy Computing vizyonunun hedefi, tüm Microsoft uygulamalarının daha güvenli ve güvenilir olmasını sağlamaktır. Trustworthy Computing vizyonunun bir parçası olarak SQL Server 2005, güvenlik alanında çok önemli yenilik ve iyileştirmelerle birlikte gelmektedir. SQL Server 2005’in geliştirme grubu ürünün tasarımdan, dağıtıma, çok daha sağlam ve güvenli olmasına odaklanarak çalıştı. SQL Server 2005’in güvenlik tasarımında Microsoft bir kaç temel güvenlik kuralına bağlı kaldı. İlk olarak kurulum sırasında tüm standart ayarları sistemi en güvenli kılacak şekilde belirledi. Kullanıcılar daha az güvenli olan diğer seçenekleri ihtiyaçları doğrultusunda kullanabiliyor olsalar da, standart ayarlar, sistemin en yüksek güvenlik seviyesini yakalamasına odaklanmıştır. İkinci olarak sistem tasarımı en az yetki gerektirecek şekilde yapıldı. Son olarak Microsoft potansiyel risk alanını sadece gereksinim duyulan bileşenleri kurarak minimuma indirgemeyi hedeflemiştir.

SQL Server 2005’te yer alan tüm güvenlik özellikleri, Microsoft’un 2002 yılının başlarında geliştirdiği güvenlik tekniklerinden etkilenmiştir. Bu bölümde ele alacağımız güvenlik özelliklerinden başlıcaları; kullanıcıların şemalardan ayrılmasını, yeni stored procedure çalıştırma konseptini, daha detaylı yetki kontrolünü, yeni password policy sistemini, row-level Security’de yer alan yenilikleri ve kataloglar için geliştirilmiş güvenlik tekniklerini içermektedir.

Kullanıcı – Şema Ayrımı
SQL Server 2005’te gelen en önemli güvenlik değişikliklerin başında, kullanıcı-şema ayrımı gelmektedir. Bir kullanıcı veya daha doğru söylemek gerekirse bir principal, veritabanı nesnelerinin kendisine karşı korunduğu bir varlıktır. Principal bir Windows kullanıcısı, SQL Server kullanıcısı, bir rol veya bir application role olabilir. SQL Server 2000 ile veritabanı nesneleri doğrudan kullanıcılara aitti ve bu kullanıcılar sys_users sistem tablosunda kayıtlı tutulmaktaydı. SQL Server 2005’te bu yapı tümüyle değiştirildi ve veritabanı nesnelerinin sahipliği şemalara verildi. Kullanıcılar ise artık doğrudan veritabanı nesnelerinin sahibi durumda değil, şemaların sahibi durumunda oluyorlar. SQL Server 2005 ile birlikte kullanıcılar ve diğer güvenlik principal’ları yeni sys.database_principals adlı view ile görüntülenebilmektedir. SQL Server 2005’in şema listesine ise sys.schemas view’ı ile erişilebilir.

Şemayı çeşitli nesneler için bir container olarak düşünebiliriz. Şema, SQL Server tarafından kullanılan dört bölümlü isimlendirme yapısının üçüncü bölümü tarafından tanımlanmaktadır. Aşağıdaki örnek SQL Server 2005’in isimlendirme söz dizimini örneklemektedir.

sunucu_adi.veritabani_adi.schema_adi.nesne_adi

SQL Server’ın önceki tüm sürümlerinde schema ismi ve owner’ın ismi genellikle aynı olurdu. SQL Server 2005 ile birlikte owner, schema’dan ayrılmış durumdadır. SQL Server 2000 ve önceki sürümler nesne isimlerini çözümlerken SQL Server ilk olarak veritabani_adi.kullanici_adi.nesne_adi’na bakıyor ve çözümleme başarısız oluyordu, daha sonra ise veritabani_adi.nesne.adi’na bakıyordu.

SQL Server 2005’te kullanıcı ve şemanın ayrılmasının temel nedeni, bir kullanıcıya ait çok sayıda nesnenin ownership’liğini değiştirme ihtiyacıydı. Ek olarak, bir veritabanı nesnesinin isminin değişmesi aynı zamanda bir isim değişikliğine neden oluyordu. Örneğin MyDB veritabanında yer alan Tablo1’in ownerı KullanıcıA’dan KullanıcıB olarak değiştirildiğinde tablonun ismi MyDB.KullanıcıA.Tablo1’den MyDB.KullanıcıB.Tablo1’e dönüşmektedir. Bu problemi önlemek için çoğu kurum tüm veritabanı nesnelerinin dbo tarafından sahiplenilmesi şeklinde bir standart uygulama kullanmaya başladı.

SQL Server 2005’in veritabanı ownership zincirini şekil 1.2’de görebilirsiniz.

Şekil 1.2 :: SQL Server 2005, Veritabanı Ownership Zinciri

SQL Server 2005 ile birlikte veritabanı nesneleri şemalar içinde bulundurulmaya ve şemalar kullanıcılar tarafından own edilmeye başladı. Bu yeni soyutlama modeli veritabanı nesnelerinin sahibinin belirlenmesi ve değiştirilmesini kolaylaştırarak daha kolay yönetilebilir bir yapı oluşmasını sağladı. SQL Server 2005’te veritabanında herhangi bir nesnenin sahibi durumundaki bir kullanıcının silinmesi sadece DBA’in ilgili tüm nesnenin/nesnelerin ownerını değiştirmesi değil, sadece bu nesneleri içeren şemanın sahibinin değiştirilmesi anlamına geliyor. Bu DBA’in yapması gereken işlem ve müdahale edilmesi gereken nesne sayısını azaltarak, ilgili şemanın güncellenmesinden sonra ilgili kullanıcı accountunun drop edilerek işlerin çok daha hızlı tamamlanabilmesini sağlıyor. Ek olarak nesnenin / nesnelerin ismi değişmemiş oluyor.

Tabi bu değişikliklerle birlikte SQL Server’ın veritabanı nesnelerinin isimlerini çözümlemede kullandığı yöntem de değişiyor. Artık her kullanıcı için kullanıcı il ilişkilendirilmiş varsayılan bir şema mevcuttur ve SQL Server 2005 ilk olarak kullanıcının varsayılan şemasına bakar. Eğer başarısız olursa SQL Server nesneye dbo’nun şema ismine bakarak erişmeye çalışır. Örneğin KullanıcıA varsayılan şema olarak SchemaA ile ilişkilendirilmişse ve bu kullanıcı Tablo1 üzerinde bir sorgu çalıştırırsa, SQL Server ilk olarak SchemaA.Tablo1’i kullanarak isim çözümleme yapmaya çalışacak başarısız olursa dbo.Tablo1’e bakacaktır.

SQL Server 2000 veritabanlarının birden çok kullanıcı ve rol içerebildiği gibi SQL Server 2005 veritabanları da birden çok şema içerebilir. Her şema kendisine özgü bir kullanıcı veya rol olan principal’a sahiptir. İsim çözümleme işlemleri için her kullanıcı varsayılan bir şemaya sahiptir, veritabanı nesneleri ise şema içinde yer alır. Şema içinde yeni veritabanı nesneleri oluşturmak için ilgili nesne için CREATE, ilgili şema üzerinde ise ALTER veya CONTROL yetkileri olması gerekir. Ownership zinciri hala şemalara değil gerçek ownera dayanmaktadır.

SQL Server 2005 kullanıcı ve şema ayrımını desteklemek için USER, ROL ve SCHEMA nesneleri için CREATE, DROP, ALTER ifadelerinde pek çok DDL değişikliği ile gelmektedir.

Aşağıdaki kod, bir veritaanı şemasının nasıl oluşturulduğunu ve assign edildiğini örneklemektedir.

/* Yeni bir login oluştur */

CREATE LOGIN UserA WITH PASSWORD = ‘ABC123#$’

GO

/* Oluşturulan login için bir kullanıcı oluştur. Şema varolmak zorunda değildir */

CREATE USER UserA FOR LOGIN UserA

WITH DEFAULT_SCHEMA = MySchema

GO

/* Şemayı oluştur ve ownerı ile ilişkilendir */

CREATE SCHEMA MySchema AUTHORIZATION UserA

GO

/* Yeni şemanın içinde bir tablo oluştur */

CREATE TABLE MySchema.Table1 (col1 char (20))

GO

Örneğin ilk satırı UserA adlı yeni bir login oluşturuyor ve bir parola belirliyor. İkinci satır oluşturulan login için yeni bir kullanıcı oluşturuyor ve varsayılan şemayı belirtiyor. Bu aşamada belirtilen şemanın varolması gerekmemektedir. Yeni kullanıcı oluştururken varsayılan şemayı belirtmezseniz dbo ile aynı varsayılan şema kullanılacaktır. Sonraki adımda CREATE SCHEMA ifadesi ile MySchema adlı şema oluşturuluyor. AUTHORIZATION ifadesi şemanın ownerının UserA olduğunu belirtiyor ve şema içinde Table1 adlı bir tablo oluşturuluyor.

Stored Procedure Execution Context
Microsoft Stored Procedure Execution Context adlı bir özelliği deklare etmiş olsa da, bu özellik stored procedure’ler dışındaki modüller için de (fonksiyonlar veya assemblyler) geçerlidir. Bir modül için execution context belirtmek modülün içeridği tüm ifadelerin belirtilen execution context’e bağlı olarak yetki denetiminden geçirilmesine neden olacaktır. Diğer bir deyişle, bir modül için execution context’in belirtilmesi, modülün kapsadığı tüm ifadelerin, modülü çalıştıran kullanıcı yerine belirtilen kullanıcının ownershipliğinde çalıştırılması anlamına geliyor (İki kelime ile özetlemek gerekirse: identity impersonation diyebiliriz). Şekil 1.3 SQL Server 2005’in ownership mimarisini göstermektedir.

Şekil 1.4 :: SQL Server 2005 Ownership Mimarisi

UserA’nın dbo.Proc1’i çalıştırabilmesi için UserA’nın bu nesne üzerinde execute yetkisinin olması gerekiyor. Ancak dbo.Proc1, dbo.Table1’e eriştiğinde herhangi bir yetki denetimi yapılmıyor, çünkü dbo her iki nesneninde ownerı durumunda. Sonraki senaryoda, UsrA’nın UserB.Proc2’yi çalıştırabilmesi için, bu nesne üzerinde yetkiye gereksinimi var. Sonrasında UserB.Proc2, UserC.Table2 nesnesine erişmek istediğinde, UserA için SELECT yetkisi denetlenmek durumunda. Bu senaryoda, UserB.Proc2 ve UserC.Table2 farklı ownerlara sahip ve ownership zinciri kırılıyor.

SQL Server 2005 bu senaryoyu şekil 1.4’te görüldüğü üzere oldukça kolaylaştırıyor. Bu senaryoda UserA, UserB.Proc2’yi çalıştırmak istiyor ve SQL Serer UserA’nın UserB.Proc1 için Execute yetkisinin olup olmadığını denetliyor. Eğer UserB.Proc1 nesnesi, UserZ’nin contextinde çalıştırılacak şekilde oluşturulursa, UserB.Proc1 stored procedure’u UserC.Table1 nesnesine erişmeye çalıştığında SQL Server sadece işlemi gerçekleştiriyor olarak kabul edilecek kullanıcının, yani bu örnek için UserZ’nin yetkilerini denetleyecektir. İşlemi başlatan kullanıcı olan UserA için SELECT yetkisi aranmayacaktır.

Şekil 1.4 :: SQL Server 2005 execution context

Aşağıdaki kod MyProc1 adlı bir stored procedure’ın execution context’ini nasıl değiştirebileceğimizi örneklemektedir.

ALTER PROC MySchema.Proc1 WITH EXECUTE AS USER UserB

Bu ifade yeni WITH EXECUTE ifadesini kullanmaktadır. Burada MySchema içinde yer alan Proc1 adlı stored procedure UserB’nin context’inde çalıştırılmak üzere güncelleniyor. Bu işlemde bir kullanıcı adı belirtmemiz gerekiyor, bir rol ismi kullanamıyoruz. Execution Context’te yapılan değişiklikler sys.sql_modules view’ı aracılığıyla görüntülenebilmektedir.

Daha Detaylı Yetki Yönetimi
SQL Server 2005 önceki sürümlere göre çok daha detaylı yetkilendirme yapmamıza imkan veriyor. SQL Server 2005 ile birlikte pek çok farklı seviyede, farklı yetkilendirmeler yapılabiliyor. Yetkilendirmelerin uygulanabileceği seviyeler: sunucu, veritabanı, şema, nesne ve principal şeklindedir. SQL Server 2005’in gelişmiş yetkilendirme sisteminin arkasındaki fikir, DBA’in kime hangi yetkilerin verildiğini tam olarak kontrol edebilmesini ve mümkün olan en az yetki ile çalışmasını sağlamaktır. Yeni sistem, SQL Server’ın mevcut rollerini ortadan kaldırmıyor. SQL Server 2000’de yer alan tüm roller sorunsuz olarak yeni yetkilendirme sistemi ile bir arada çalışmayı sürdürüyor.

GRANT, DENY ve REVOKE gibi temel yetkilendirme ifadeleri geçerliliklerini halen korumakta. SQL Server 2005’te farklılık gösteren bir nokta, aynı yetkinin farklı seviyelerde uygulanabilmesi. Örneğin, eğer veritabanı seviyesinde bir yetkilendirme yapıyorsanız, yaptığınız yetkilendirme veritabanındaki tüm nesneleri etkileyecektir. Eğer yetkilendirmeyi şema seviyesinde yaparsanız, yetkilendirme şemanın içerdiği tüm nesneler için uygulanacaktır. Tablo 1.1 SQL Server 2005’te yer alan bazı önemli yetkilendirmeleri listelemektedir. Sunucu yetkilendirmeleri sys.server_permissions view’ı, veritabanı yetkilendirmeleri ise sys.database_permissions view’ı aracılığıyla görüntülenebilir.

Password Policy Sistemi
SQL Server 2005’te yer alan bir diğer önemli güvenlik özelliği ise password policy’ler. Yeni policy enforcement özelliği yerel Windows password policy’lerini izleyerek, kurumsal ölçekte sadece Windows Server sistemlerde değil, SQL Server sistemlerde de tutarlı bir Security policy oluşturmanızı mümkün kılar. SQL Serer 2005 artık parola kompleksliği, geçerlilik süresi ve account lockout policy’lerini destekliyor. Bu özelliklerden, Windows 2000 serverda desteklenen parola kompleksliği dışında tamamı Windows Server 2003 tarafından desteklenmektedir. Tüm bu güvenlik önlemleri, varsayılan kurulumda aktif haldedir ancak kurulum sonrasında değiştirilebilmektedir. SQL Server 2005 password policy’leri sys.sql_logins katalog view’ında saklar.

Katalog Güvenliği
Bu bölümde ele alacağımız son güvenlik yeniliği, catalog Security özelliği. Farklı veritabanlarında ve master veritabanında saklanan SQL Server 2000 tarafından kullanılan sistem tabloları, SQL Server 2005’te catalog view’larında toplanmıştır. Bu view’lar tarafından sunulan metadata varsayılan olarak korunma altına alınmıştır ve çok kısıtlı public yetki söz konusudur. SQL Server 2005’in catalog view’ları, içerdikleri verilere sadece nesnelerin ownerı olmanız veya gerekli yetkilere sahip olmanız durumunda erişebilmenizi sağlayan, row-level Security uygulamaktadır. Doğal olarak sa kullancısı bu durum için bir exception’dır. Sa accountu halen sunucu üzerindeki her nesneye tam erişim yetkisine sahip durumdadır.

Bir kullanıcı veya rolün metadata’ya erişmesini sağlamak için DBA’in VIEW DEFINITION yetkisini kullanması gerekir. VIEW DEFINITION yetkisi bir kullanıcıya, owner’ı olmadığı veya erişim hakkı olmayan bir nesne üzerinde, nesnenin metadata’sına erişme imkanı vermek amacıyla kullanılır. VIEW DEFINITION yetkisi sunucu, veritabanı, şema veya nesne seviyesinde uygulanabilir.

Bir sonraki bölümde SQL Server 2005’te veritabanı yönetimi ve programlaması alanlarındaki yenilikleri ele alıyor olacağız.

Kullanılan Kaynaklar;
SQL Server 2005 Books Online
SQL Server 2005 MSDN Site

Kadir Sümerkent
kadir@sumerkent.com

21 Kasım 2007
Yazar: | Kategori: Genel
Yorum: 0

SQL Server Güvenliği

 

Windows 2000/2003 Server da var olan kullanıcı yetkileri, kullanıcıların domain içinde veya lokaldeki üyelikleri sistem güvenliği için çok önemlidir. Aynı şekilde  SQL Server 2000’de de kullanıcılara tanımlanan oturumları, izinleri ve rolleri detaylı bir şekilde bilmek ve bu gereksinimlere göre tanımlamalar yapmak sistem güvenliğini sağlamak açısından belirleyici özelliklerdir.Atadığınız roller ve izinler veritabanına bağlanan kullanıcıların hangi tür veriye ulaşabileceklerini veya neleri yapıp yapamayacaklarını belirler.

 

SQL Server Güvenlikleri dört ana başlıktan oluşmaktadır. Bunlar;

  • SQL Server Kimlik Doğrulama Kipleri
  • Sunucu Oturumları
  • İzinler
  • Roller

 

1.Adım Olarak SQL Server Kimlik Doğrulama Kipleri

SQL Server’da iki tür kimlik doğrulama kipi vardır

Windows Authentication Only:Windows etki alanında bulunan kullanıcı ve grup hesaplarını kullanabilirsiniz.Domain’de (etki alanında) tanımlı kullanıcılara birde SQL Server oturum açma adı ve parolası vermenize gerek kalmadan veritabanlarına erişim yapabilirler.

Karma Güvenlik: Veritabanına şirket dışından erişim oluyorsa, etki alanı kullanılmıyorsa Karma Güvenlik kipiyle veritabanlarına erişim sağlanabilir.

SQL Server kimlik doğrulama kiplerini görmek için Enterprise Manager tıklayın çalışmak istediğiniz Sunucuyu içeren sunucu grubuna erişin, sonra da ve Enterprise Manager ağaç yapısındaki sunucu adını farenin sağ düğmesiyle tıklayın ve özelikleri seçin. Security tabında kimlik doğrulama modları yer almaktadır.

 

2.Adım Olarak Sunucu Oturumları

İki tür kimlik doğrulama kipi bulunduğu gibi iki türde sunucu oturumu mevcuttur. Etki alanın oturumlarını, etki alanında ya da yerel kullanıcı hesabını yerel grup hesaplarında ya da evrensel veya genel etki alanı grup hesapları olabilen etki alanı hesaplarını kullanarak yaratabilirsiniz. SQL Server oturumlarınız unique (benzersiz) bir oturum adı ve parola belirleyerek yaratırsınız. Varsayılan ayar olarak gelen oturumlar aşağıda yer almaktadır.

  • Yerel Administrators grup
  • Yerel Administrator hesabı
  • sa oturumu
  • guest oturumu
  • dbo oturumu

 

3.Adım Olarak İzinler

İzinler, kullanıcıların SQL Server üzerinde yada bir veritabanında yapabileceklerini belirler ve kullanıcılara oturum kimlik’ine ,grup üyeliğine ve rol üyeliğine göre verirler.Kullanıcıların veritabanında bir değişiklik yapma yada bir şeyi silme gibi eylemleri gerçekleştirmeden önce uygun izinlere sahip olmaları gerekmektedir.

SQL Server izinler üç ana başlıkta toplanır:

  • Nesne izinleri (object permissions)
  • Bildiri izinleri (statement permissions)
  • Kendiliğinden izinler (implicit permissions)

 

Nesne İzinleri:Tablo ,görünüm ve sütunları erişimi düzenleyen izinlerdir.Örneğin sadece raporlama üzerinde çalışan bir kullanıcıya bir tablodan sadece bilgi seçme (select) hakkı verilebilir,bu kullanıcı tabloya herhangi bir bilgi ekleme(insert),güncelleme(update) ve silme(delete) yetkisi vermeyebiliriz

 

Nesne Türü                                   Eylemler

Column                                          select ve update

Row                                               N/A(Tablo düzeyinde ayarlanır)

Stored Procedure                           Execute

Table                                              Select,insert,update,delete ve references

View                                              Select,insert,update,delete

 

Bildiri İzinleri:Bir veritabanı yaratmak veya bir veritabanına nesne eklemek için kullanılan yönetici izinleridir.Bu tür izinleri System Administrators rolüne sahip üyeler kullanabilir.Varsayılan ayarlarda normal oturumlara bildiri izinleri verilmez,daha sonra isteğe bağlı olarak verilebilir.Örneğin bir kullanıcıya veritabanını yedekleme izni vermek istiyorsanız backup database yürütme izni verilmelidir.Bu tür izinler verilebilir ve daha sonra o kullanıcıda geri alınabilir izinlerdir.Bu izinler aşağıda yer almaktadır:

Create Database: Kullanıcının Veritabanı yaratıp yaratmayacağı belirler.

Create Default: Kullanıcının tablo sütunu içinde varsayılan bir değer yaratıp yaratmayacağını belirler.

Create Function: Kullanıcının veritabanında kendi tanımladığı bir işlev değer yaratıp yaratmayacağını belirler.

Create Procedure: Kullanıcının saklı yordam değer yaratıp yaratmayacağını belirler.

Create Rule: Kullanıcının bir tablo sütunu değer yaratıp yaratmayacağını belirler.

Create Table: Kullanıcının bir tablo değer yaratıp yaratmayacağını belirler.

Create View: Kullanıcının bir görünüm değer yaratıp yaratmayacağını belirler.

Backup Database: Kullanıcının veritabanını yedekleyip yedekleyemeyeceğini belirler.

Backup Log: Kullanıcını işlem günlüğünü yedekleyip yedekleyemeyeceğini belirler.

 

Kendiliğinden İzinler: Önceden tanımlı rollerin üyeleri yada veritabanı nesnesi sahiplerin kendiliğinden olan izinleridir. Kendiliğinden olan izinler değiştirilemezler. Örneğin System Administrators’ın SQL Server’da tüm eylemleri gerçekleştirebilmesi gibi.

 

4.Adım Olarak Roller

Bir grup kullanıcıya kolayca izin atayabilmek için kullanılan ve değiştirilemeyen önceden tanımlı izinlerdir.

  • Sunucu Rolleri
  • Veritabanı Rolleri

 

Sunucu Rolleri: Sunucuyu yönetebilmek için kullanılır. Sunucu rolleri sunucu düzeyinde ayarlanır ve önceden tanımlıdırlar. Bu izinler tüm sunuyu etkiler ve değiştirilemezler.

Resimdeki sunucu rollerinin açıklamaları ise şu şekildedir.

Bulk Insert Administrators(bulkadmin): Veritabanına yığın eklemeleri yapmaları gereken etki alanı hesapları için tanımlanmış roldür. Bu rolün üyeleri bulkadmin’e üyeler ekleyebilir ve Aşağıda belirtilen izinlere sahiptirler.

Database Creators(dbcreator): Veritabanı yaratma, değiştirme ve iptal etme yetkisini içeren roldür. Aşağıda belirtilen izinlere sahiptirler.

 

Disk Administrators(diskadmin):Disk dosyalarını düzenleyebilme yetkisi verilmek istenen kullanıcılara atanan roldür. Aşağıda belirtilen izinlere sahiptirler.

Process Administrators(processadmin): SQL Server işlemleri denetleyebilme yetkisine sahip kullanıcılar bu role eklenirler. Process admin’e üye ekleyebilirler ve işlemleri kesebilirler.

Securtiy Administrators(securityadmin):Oturumları düzenler, veritabanı izinleri yaratır ve hata günlüklerini okuması gereken kullanıcılar bu role eklenirler. Aşağıdaki izinlere sahiptir.

Server Administrators(serveradmin): Sunucu ayarlamaları yapabilmesi ve sunucuyu kapatılabilmesi gereken kullanıcılar bu role eklenirler ve aşağıda yer alan izinlere sahiptirler.

Setup Administrator(setupadmin):Bu role üye kullanıcılara setup admine üye ekleyebilir ve bağlı sunucular ekleyip silebilirler.Aşağıda yer alan izinlere sahiptirler.

System Administrators(sysadmin): SQL Server üzerinde tam denetime sahip olması istenen kullanıcılarda sysadmin’de olmalıdırlar. SQL Server’da tüm uygulamaları yerine getirebilirler.

Veritabanı Rolleri: Veritabanı üzerinde izinler atamak istediğinizde veritabanı rollerini kullanabilirsiniz. Bu roller veritabanları için tek tek ayarlanır, yani bir kullanıcının her veritabanında farklı rolleri olabilir.

 SQL Server’da önceden tanımlı veritabanı rolleri mevcuttur. Önceden tanımlı roller yerleşiktir ve değiştirilemeyen izinleri vardır. Aşağıda önceden tanımlı roller ve açıklamaları yer almaktadır.

db_accesadmin: Bir veritabanına oturum ekleme ve çıkarma yetkisine sahip olması gereken kullanıcılar bir role üye edilmelidir.

db_backupoperator: Veritabanı yedeklemesi yapması gereken kullanıcılar bu role üye olmalıdırlar.

db_datareader: Veritabanından veriyi görüntüleyebilirler.

db_datawriter: Veritabanı üzerinde değişiklik yapabilme yetkisine sahip kullanıcılar bu role üye yapılmadırlar. Bu role üye kullanıcılar delete, insert ve update işlemlerini yapabilirler.

db_ddladmin: Bu role üye kullanıcılar SQL Server’ın veri tanımlama dili (data definition language-ddl)ile ilgili haklara sahip olurlar.

db_denydatareader: Veritabanı oturumunda olan kullanıcıların veriye erişimini kısıtlamak için oluşturulan roldür. Veritabanındaki tüm nesnelerde select izinlerini yasaklayabilir veya geri alabilirler.

db_denydatawriter: Bu rolün üyeleri Veritabanındaki tüm nesnelerden insert,update ve delete izinlerini yasaklayabilir yada geri alabilirler.

db_securityadmin: İzinleri ,nesne sahipliğini ve rolleri düzenleyebilmesi gereken kullanıcılar bu role üye edilmelidir.

 db_owner: Veritabanı üzerinde her türlü denetime gereksinimi olan kullanıcılar bu role üye edilmelidirler. Bu rolün üyeleri izinleri atayabilir, veritabanı ayarlarını değiştirebilir, veritabanına bakım uygulayabilir ve veritabanı üzerinde diğer tüm yönetim görevlerini gerçekleştirebilir.

public: Tüm veritabanı kullanıcılarına varsayılan olarak gelen bir roldür. En düşük izin ve ayrıcalıklarını taşımaktadır. Bir kullanıcıya public dışında atadığınız her rol, yeni ayrıcalık ve izin ekler.

 Yukarıda açıklamaları yapılan Veritabanı Rollerine istenirse kendinizde yeni Veritabanı Rolleri ekleyebilirsiniz. Yeni Rol eklemek istediğiniz veritabanına girin ve Roles’ın üzerinde farenin sağ tuşu ile New Database Role seçin.

Kendinizin eklemek istediğiniz yeni Veritabanı Rolünün adını yazın ve Standard Role altında yer alan Add butonuna basın ve bu role üye yapmak istediğiniz kullanıcıyı ekleyin.

Permissions butonuna basarak açılan pencereden eklediğiniz kullanıcının o veritabanındaki hangi işlemleri yapmasını ve yapmamasını istiyorsanız bu ayarlamaları yapın.

Columns butonuna basarak izni düzenlediğiniz veritabanında kullanıcının kolonlarda ne çeşit işlemler yapıp, yapamayacağını ayarlarsanız.

Bu işlemlerle oturum ile nesne izinleri sağlamış olursunuz.

Sunucu oturumlarının, İzinlerin ve Rollerin kullanıcılar üzerindeki etkilerini öğrendikten sonra çalışmak istediğiniz sunucuda bir kullanıcı yaratmayı ve tüm yukarıda anlatılanların nasıl yapıldığını bir örnekle tamamlayıp, SQL Server’da Güvenlik konusunu tamamlayalım.

 Varolan oturumları görmek için Enterprise Manager’ başlatın ve çalışmak istediğiniz sunucuya gelin, Sunucunun Security klasörünün altındaki Logins girişini seçin.

Resimde sağ tarafta yer alan Name,Type,Server Access,Default Language ve Default Database açıklamaları ise şu şekildedir.

Name :Oturum adı,

Type: Standard SQL Server’daki oturumları,Etki alanı kullanıcısı için Windows User ve Etki alanı grup hesaplarını Windows Group göstermektedir.

Server Access: Kullanıcın sunuya erişim iznini gösterir,Permit izinin var olduğunu,Deny olmadığını belirtir.

Default Database: Kullanıcı için varsayılan veritabanını.

Default Language: Kullanıcı için atan dili göstermektedir.

 Logins üzerinde farenin sağ tuşuna basın ve New Login seçin.

 

Yukarıdaki Resimde Windows Authentication’a göre açılan kullanıcı görülmektedir.

Yukarıdaki resimde ise SQL Server Authentication’a göre açılan kullanıcı görülmektedir.İstediğiniz  kimlik doğrulama tipine seçtikten sonra.Server Roles ve Database Access’leri tanımlamanız gerekmektedir.

Server Roles’da, kullanıcıya Sunucu üzerindeki rolleri tanımlanır bu rollerin ne tür izinler ve yetkiler verdiği daha önceki bölümlerde anlatılmıştı

Database Access’le  ise kullanıcının hangi veritabanına login olabileceğini ve bu veritabanı üzerinde nasıl izinleri sahip olacağı bu alanda tanımlanır.

Eğer daha sonraki günlerde SQL Server Authentication’a göre açılan kullanıcı şifresinin değiştirilmesi isteniyorsa Password alanına yeni şifre yazılır ve confirm kutusuna aynı şifre onaylanır.

Açılan kullanıcı şirketinizden ayrılmış veya herhangi bir sebepten dolayı kullanıcı için açılan hesabı kaldırmak istiyorsanız.Kaldırmak istediğiniz kullanıcın üzerinde farenin sağ tuşu ile tıklanır ve Delete (sil)seçilir.

 

 

Veritabanı Yöneticisi olarak, SQL Server Kimlik Doğrulama Kiplerini, Sunucu Oturumlarını, İzinleri ve Rolleri kâğıt üzerinde daha önceden belirler ve bu prosedüre göre işlemler yaparsanız sonradan çıkabilecek büyük güvenlik sorunlarını önlemiş ve daha az performansla daha kolay bir yönetim yapmış olursunuz.

 Kaynak:

microsoft.com

70-228: Microsoft SQL Server 2000 System Administration Training

Bir sonraki Makale’de Görüşmek Üzere…

 

Yazar: | Kategori: Genel
Yorum: 0

MICROSOFT Windows SERVER 2008

    Microsoft yeni jenerasyon Server platformu olan Windows Server 2008’i geçtiğimiz aylarda duyurdu. Windows Server Sistemleri zincirinin son halkasını oluşturacak olan 2008, getirdiği yeniliklerle henüz Beta aşamasında bile kendinden söz ettirmeye başladı. Biz de önümüzdeki 5 yıla damgasını vurması beklenen Server 2008’in çarpıcı özelliklerine, yeniliklerine ve değişimlerine bir göz atacağız.

Windows Server 2008’in şüphesiz en önemli özellikleri arasında güvenlik temelleri ve uygulama yönetimi esasları yer almaktadır. 2008, web tabanlı uygulamaların ve hosting bileşenlerinin çok daha esnek ve efektif bir şekilde kullanılabilmesine imkan sağlamasıyla da çok konuşulacak gibi duruyor.

Şimdi gelin bu yeni platformun özelliklerini; web uygulamaları, güvenlik, merkezi uygulama yönetimi gibi ana kategoriler halinde değerlendirelim.

    Performans:

Performans yönetimi ve performans araçlarına değinmeden önce Windows Server 2008’in donanımsal gereksinimlerine bir göz atalım;

İşlemci

• Minimum: 1GHz
• Tavsiye Edilen: 2GHz
• Yüksek Performans: 3GHz veya üzeri

Bellek

• Minimum: 512MB RAM
• Tavsiye Edilen: 1GB RAM
• Yüksek Performans: 2GB RAM (Normal Yükleme) veya 1GB RAM (Server Core Yüklemesi) veya üzeri
• Maksimum (32-bit için): 4GB (Standart) veya 64GB (Enterprise ve Datacenter)
• Maksimum (64-bit için): 32GB (Standart) veya 2TB (Enterprise, Datacenter, ve Itanium tabanlı sistemler)

Disk Alanı

• Minimum: 8GB
• Tavsiye Edilen: 40GB (Full installation) veya 10GB (Server Core installation)
• Yüksek Performans: 80GB (Normal Yükleme) veya 40GB (Server Core Yüklemesi) veya üzeri
Note: 16 GB’dan yüksek belleğe sahip bilgisayarlar; paging, hibernation, veya dumping için daha fazla disk alanına ihtiyaç duyacaklardır.

Sürücü Gereksinimi

DVD-ROM sürücü

Görüldüğü üzere Server 2008, sunmuş olduğu yüksek performans ve güvenlik eklentilerine karşılık çok yüksek sistem gereksinimi duymamaktadır. Server kurulumuna göre değişiklik gösteren bellek yapısı sayesinde yükleme seçeneklerini kendi ihiyaçlarınıza ve yapınıza göre değerlendirebilirsiniz.

Server Core yapısı olarak adlandırılan yeni model ile Microsoft, arabirim ve bunun getirdiği performans düşüklüğünü ortadan kaldırmak amacıyla tamamen komut satırından yönetime imkan veren bir yapıyı gündeme getirdi. Bir başka performans gelişimi olarak multi-core desteği her bir sanal makine için 8 adet mantıksal işlemciyi imkanlı kılıyor. 32 ve 64 bit mimarisine sahip sanal serverların aynı fiziksel server üzerinde çalışabilmesi artık mümkün. Uygulamaların sanal serverlar üzerinde çok daha performanslı çalışacağına dikkat çeken bu gelişim sayesinde fiziklsel ve mantıksal bütünlük çok iyi koordine edilmiş gözüküyor.

    Kolay Yönetim:

Server yönetimi dendiğinde; kullanışlı, hızlı ve çözüme yakın araçlara sahip olmak her zaman önce gelir. Bu yönüyle 2008 Server yöneticilerine önemli araçlar sunmaktadır. Bunlar içerisinde en çarpıcı olanı şüphesiz PowerShell. Yeni nesil komut satırı mimarisiyle çok daha esnek ve efektif sonuçlar alınabilmektedir. Yine vazgeçilmez bir konsol olan Microsoft Management Console 3.0 sayesinde Windows servisleri, araçları ve denetim ilkeleri çok daha uyumlu ve hızlı işlenebilmektedir. Micorosft System Center yapısıyla tam uyumluluk gösteren 2008, ileride güçlendirilmiş Microsoft Server araçlarıyla ciddi performans optimizasyonu sağlayacak gibi gözüküyor. Güçlendirilmiş Windows Management Instruments (WMI) ve Group Policy teknolojilerinin de desteğiyle server yönetimi konusunda çok önemli adımların atıldığı görebiliyoruz.

    Microsoft Windows Server 2008’in yeni nesil yönetim konsolu Server Manager sayesinde tek bir konsoldan bütün server yapılandırmaları ve bakımları yapılabilmektedir. Server Manager ile serverin durumu, sürücü problemleri, güncelleştirmeler, yedekleme, felaket yönetimi gibi bir çok seçenek karşımıza çıkabilmektedir.

    Microsoft Windows Server 2008, server üzerine yeni bir rol ekleme noktasında oldukça başarılı bir hale getirilmiş. Artık tek bir konsol üzerinden istediğiniz bütün rolleri bir kereye mahsus olmak kaydıyla seçip bir çırpıda yükleyebilir ve tek “restart” ile bütün kurulumlarınızı tamamlayabilirsiniz.

    Windows ServerCore

ServerCore sayesinde, yönetim araçlarını çok daha hızlı ve güvenli bir biçimde kullanabilirsiniz. Bunun amacı, gereksiz uygulamaların, arayüzlerin ve servislerin bu kurulum biçiminde devre dışı bırakılmış olmasıdır. Bu sayede server yöneticileri dışarıdan gelen atakları daha kolay kontrol edebilir ve sınırlı sayıda olan servis ve uygulamaların süregelen bakımlarını çok daha etkili bir biçimde yapabilirler.

    Şimdi ServerCore ile Full Server 2008 arasında rolleri bakımından farklılıklara bir göz atalım.

Windows Server 2008 Rolleri Active Directory Certificate Services Active Directory Domain Services Active Directory Federation Services Active Directory Lightweight Directory Services Active Directory Rights Management Services Application Server DHCP Server DNS Server Fax Server File Services Network Policy and Access Services Print Services Streaming Media Services Terminal Services UDDI Services Web Server Windows Deployment Services Windows SharePoint Services Windows Server 2008 ServerCore RolleriWindows Server Virtualization

Dynamic Host Configuration Protocol (DHCP)

Domain Name System (DNS)

File server

AD Directory Services (AD DS)

AD Lightweight Directory Services (AD LDS)

Windows Media Services

Print Management

    Arttırılmış Güvenlik:

Birçok yeni güvenlik aracını beraberinde getiren ve bugüne kadarki en güvenli Windows Server olan 2008, adeta istemci bilgisayarlara daha yüksek güvenlik vaat edebilmek için yapılandırılmış. Gerek kendi üzerinde barındırdığı yeni araçlar ve gerekse Windows Vista ile tam uyum sağlayan özellikleri ile güçlü bir güvenlik kalkanına sahip olduğunu gösteriyor. Kernel yapısının korunması amacıyla oluşturulan PatchGuard sayesinde işletim sistemi çekirdeğinden arabirimine kadar korunmuş oluyor. Dolayısıyla korsanların işletim sistemine herhangi bir zararlı yamam eklemeleri riski ortadan kalkıyor. Bunun yanında dosya sistemiyle beraber Servis Yönetimi’ne de ayrı bir boyut kazandıran “Service Hardening” özelliği sayesinde Windows Servisleri’nin yönetimi ve güvenliği sağlanmış oluyor. Network Access Protection (NAP) ve güçlendirilmiş Public Key Infrastructure (PKI) sayesinde verilerin ve uzak erişimlerde kimlik doğrulama sürecinin çok daha güvenli olacağını söylemek çok doğru olacaktır.

Bir diğer güvenlik aşaması olan RODC (Read Only Domain Controller) sayesinde Domain Controller bilgisayarlar içerisinde de kritik bir güvenlik seviyesi oluşturmak mümkün hale gelebilmektedir. Bu yeni teknolojiyle beraber DC olarak görev yapan ancak üzerinde değişikliğe imkan tanımayan ve bu yönüyle saldırılara karşı çok daha güvenli bir server karşımıza çıkıyor.

Güvenlik Duvarı mimarisinde Windows Vista ile oldukça yüksek bir ivme yakalayan Microsoft, Windows Server 2008 içerisinde aynı Firewall mantığını sergiliyor. İki yönlü Güvenlik Duvarı sayesinde network içerisinden ya da dışarısından gelebilecek saldırıları bertaraf etmek artık çok daha imkanlı olacak diyebiliriz.

    Güvenlik ve Kural Yönetimi:

    Network Access Protection ve Network Policy Server

    Yine çok yeni bir teknoloji olan NAP sayesinde şirket içi ya da şirket dışı erişimlerde yüksek kontrol mekanizması işletebilirsiniz. Bu sayede network içerisindeki bir kaynağa erişimde, kullanıcıdan çeşitli kriterleri doğrulaması ve karşılaması istenmektedir. Bu kriterleri karşılayabilen kullanıcılar kendileri için özel olan bölüme ulaşabilirler ve kaynaklara erişebilirler.

    Daha önceleri Network Karantina (Network Quarantine) olarak gördüğümüz yapı artık sadece uzak VPN bağlantılarında değil şirket içi erişim kontol denetimlerinde de kullanılabilmektedir. Bu yönüyle NAP ve NPS, efektif özellikleriyle baştan sona bir erişim denetimi sağlamaktadır.

    Advanced Firewall

    Firewall mantığı, Windows Xp ile tanışmış olduğumuz bir özellik. Bu özellik uzun yıllar boyu çeşitli güncelleştirmelerle kuvvetlendirilmeye çalışıldı. İlk önceleri tek taraflı korulamar için (spesifik port bazlı olarak) yapılandırılmış olan Firewall, Windows Vista ve Server 2008 ile beraber tamamen iç-dış bütünlüğü korunarak yapılandırıldı. Dolayısıyla iç network’den dış network’e ya da dıştan içe giriş çıkış kontrolleri, port ya da program spesifik olarak güvenli bir şekilde yapılabilmektedir.

    BitLocker Drive Encryption

İlk olarak Windows Vista’nın Ultimate ve Enterprise sürümlerinde tanıdığımız BitLocker Driver Encryption teknolojisi Server 2008 tarafındanda da tam olarak desteklenmekte. BitLocker ile beraber dosya bazlı değil sürücü bazlı şifreleme yapılabilmekte ve işletim sisteminden bağımsız tam bir güvenlik sağlanabilmektedir. Şifreleme anahtarlarının fiziksel medyalarda saklanabilme imkanı olduğu gibi TPM (Trusted Platform Module) adını verdiğimiz yeni nesil modüller üzerinde de saklanabilmesini sağlamak mümkün hale gelmektedir.

    Cryptography Next Generation

    Microsoft’un yeni kripto teknolojisi olarak adlandırılan Cryptography Next Generation (CNG) ile yüksek seviyeli algoritmalar, dijital imzalar, anahtar değişimleri ve hash oluşturulabilmektedir. CNG, Amerikan Hükümeti’nin Suite B adını verdiği oluşum ile çalışmaktadır. CNG’nin avantajlarından bazıları;

-Kullanıcılar kendi algoritmalarını oluşturup kullanabilmektedirler.

-Yeni kripto servis sağlayıcılar yüklenebilmektedir.

-Elliptic curve cryptography (ECC) gibi Suite B algoritma desteği sunmaktadır.

    Read-Only Domain Controller (RODC)

Server güvenliği dendiğinde hem fiziksel hem mantıksal güvenlik akla gelir. Bu sebeple serverlarınızın barındırıldığı yerlerin güvenli olması gerekmektedir. Microsoft, bu düşünceyle farklı tipte bir domain controller oluşturma yoluna gitmiş. Adından da anlaşılacağı gibi, birincil domain controller bilgisayara bağımlı olan ve onun veritabanını kullanan read-only domain controller, fiziksel güvenliği az olan noktalar için tasarlanmıştır. Read-only domain controller yapısı, özellikle birçok şubesi olan platformlarda şubelerin daha az fiziksel güvenliği olduğu düşüncesiyle kullanılabilmektedir.    Windows PowerShell

Yeni nesil komut ve scripting sistemi olan Powershell sayesinde 130’ı aşkın komut ve geniş bir script dili yardımıyla yönetimsel faaliyetler çok hızlı ve aktif bir biçimde hayata geçirilebilmektedir. Bir script dili olması sebebiyle çok esnek ve geniş bir uygulama alanı bulunmaktadır.

Powershell hakkında detaylı bilgi için.

Windows PowerShell Getting Started Guide and Quick Reference

Powershell Download için.

http://www.microsoft.com/windowsserver2003/technologies/management/powershell/download.mspx

    IIS 7.0 ve .NET 3.0 ile Geliştirilmiş Web Uygulamaları

    Server ile birlikta gelen IIS 7.0 (Internet Information Services) ve .NET Framework 3.0 sayesinde çok gelişmiş web uygulamalarını yüksek performans ve uyumluluk ile server üzerinde çalıştırabilir ve barındırabilirsiniz. Web Server olarak kullandığınızda bugüne kadarki en gelişmiş ve hızlı servera sahip olabilirsiniz.

    Windows Yazdırma Yönetimi

    Yeni bir arabirimle karşımıza çıkan “Windows Yazdırma Yönetimi” daha önceki sürümlerdeki pooling, port yönetimi, sürücü yönetimi gibi belli başlı görevlerin yanı sıra fax-printer entegrasyonunu, XPS (xml Paper Specification) gibi yeni nesil özellikleri de sunuyor.

    Network File System

    Network File System sayesinde, Windows tabanlı bilgisayarlarınız üzerindeki paylaşımların diğer işletim sistemlerinde ve ağ ortamlarında da kullanılabilmesini sağlayabilmekteyiz.

    Windows Deployment Services (WDS)

Önceki Windows sistemlerde RIS (Remote Installation Services) olarak tanıdığımız yapıyı yeni nesil Windows içerisinde WDS (Windows Deployment Services) olarak göreceğiz. WDS sayesinde network üzerinden uzak platformlara kurulum yapılabilmektedir. İmaj mantığına göre yeniden dizayn edilen WDS çok daha hızlı ve sorunsuz kurulumlar için tasarlanmışa benziyor.

    Paylaşım ve Saklama Sunucusu (Share and Storage Server)

    Windows Server 2003 R2 ile tanışmış olduğumuz ve Server 2008 üzerinde geliştirilen WSS (Windows Storage Server), gerçek bir depolama yönetimi sunmakta. Çeşitli ünitelerde, medyalarda ve bilgisayarlarda bulunan paylaşımların tek bir merkezi konsoldan yönetilmesine imkan tanıyan WSS, Fibre Channel Fabrics desteği sayesinde hızlı veri transferi sağlıyor.

Evet arkadaşlarım, Microsoft’un Server Sistemleri içerisindeki son gözdesi olan Windows Server 2008 sunucu yapısını ilk bakışta değerlendirmeye çalıştık. Hız, performans ve güvenliği bir arada sunmayı vaat eden Server 2008, önümüzdeki yıllarda şirketlerdeki yerini alacağının sinyallerini veriyor.

Teşekkürler,
Baki Onur OKUTUCU

Microsoft Certified Trainer

Yazar: | Kategori: Genel
Yorum: 0

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…

Yazar: | Kategori: Genel
Yorum: 1

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.

Yazar: | Kategori: Genel
Yorum: 1

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.

webfarm genel.jpg

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ş

Yazar: | Kategori: Genel
Yorum: 3

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

Yazar: | Kategori: Genel
Yorum: 1

DOKUMAN İÇERİĞİ
1.)Bilgisayar Teknolojisine Giriş
2.)Network Eğitim Notları
3.)Network+
4.)Networkmimarisi
5.)TCP-IP
6.)TCP-IP ye Genel Bir Bakış
7.)IPSubnetting
8.)UTP Kablo Nasıl Yapılır (Resimli Anlatım)
9.)Adım Adım Windows 2000 Server Kurulumu (Resimli Anlatım)
10.)Active Directiory ve Dns yapılandırılması
11.)DHCP Kurulumu (Resimli Anlatım)
12.)GPMC
13.)Windows 2000 Server DNS Kurulumu (Resimli Anlatım)
14.)Windows 2000 User Accounts
15.)Windows 2000 DFS (Resimli Anlatım)
16.)Windows 2000 Server RİS (Resimli Anlatım)
17.)Windows 2000’de Network Aktivitelerinin İzlenmesi-kitap
18.)VPN (Resimli Anlatım)
19.)Windows 2000 Veri Güvenliği (Resimli Anlatım)
20.)WİNS Kurulumu (Resimli Anlatım)
21.)Volume Shadow Copy(Resimli Anlatım)
22.)IPSec
23.)System Update Service –SUS– (Resimli Anlatım)
24.)Internet Protocol Security(ıpsec) (Resimli Anlatım)
25.)MS-DOS Komutları
26.)55 Soru ve Cevap
27.)CCNA
28.)Turkce Cisco Notlari
29.)MS Windows Xp Professional Kurulumu

Download

part1 http://w15.easy-share.com/9293211.html

part2 http://w15.easy-share.com/9291591.html

Yukarı
Yazilar iin RSS aboneligi