SharePoint Server 2007 Infrastructure (Network Topology, Single-Medium-Large Farm, Load Balancing)

Kurum içersinde bazı ihtiyaçlarınızı MOSS ile efektif şekilde karşılayacağınıza karar verdikten sonra artık sistemi oluşturmaya başlayacaksınız. Altyapıyı oluşturma aşamasında bazı kararlar vermeniz gerekecektir. Kapasite, performans ve sürdürebilirlik; bunlar karar aşamasındaki anahtar kelimelerdir. Öte yandan bu sistem için ayrılmış bütçede hem yazılım hem de donanım tercihleri açısından önemlidir. Bazı uygulamalarda sürdürülebilirlik önem arz etmektedir, bazılarında ise veri güvenliği. Öte yandan uygulamanın kullanıcı sayısı ve veri hacmi büyükse bu takdirde iyi şekilde kapasite planlaması yapılmalı ve bu yönde bir mimari oluşturulmalıdır. Paylaşacağım tecrübelerim kafanızdaki tüm sorulara cevap olacaktır şeklinde bir ideam yok, fakat bazı konularda fikir sahibi olmanızı sağlayacaktır ve tüm anlatacaklarım pekte küçük ölçekli sayılmayacak bazı projelerde edindiğim deneyimler sonucudur. Küçük işletmeler de basit doküman paylaşımı ve iş süreçleri; ( Single Farm) Yaklaşık 15 kişinin çalıştığı küçük bir işletmede doküman paylaşımı için WSS 3.0 kullandığınızı varsayalım. WSS 3.0 ücretsiz malum, SQL Server’ın Express sürümü var, oda ücretsiz, yani minimum maliyetle basit bir doküman yönetim sistemi kurabilirsiniz. Sistemin durması şirketin iş akışını etkilemeyecektir (varsayımım kritik işlerin bu sistem üzerinden gerçekleştirilmediğidir) kullanıcı sayısı da az olacağından performans problemleri de yaşanmayacaktır. Bu takdirde Standalone bir sistem iş görecektir. Burada WSS 3.0 ve SQL Server tek bir makine da yayın yapabilir. Donanım olarak ortanın az üzerindeki bir desktop (Core Duo işlemci, 2 GB Ram ve 500Gb HDD) kafi gelecektir. Küçük ölçekli bir firmada sistemin kapasite planlamasıyla ilgili çok endişelenmenize gerek yok. ( Zaten bu durumda olaya yeni giriş yaptığınız için zaten bu tür kaygılarınız olmayacak doğal olarak :) ) Küçük ve orta ölçekli işletmelerde yoğun veri trafiği (Small Farm) Şimdi şirketin personel sayısını biraz artıralım ve dokümanların sayısının ve hacimlerinin daha fazla olduğunu düşünelim (örneğin 50 – 100 MB arasındaki dokümanlar mevcut olsun). Burada ihtiyacınız olan biraz daha performanstır. Sistemin performansı doğrudan DB’nin performansıyla alakalıdır ve burada SQL Server’ın performansı da doğrudan donanımla alakalıdır. DB’in performansının neden doğrudan donanımla alakalı olduğu konusu üzerinde biraz duralım. Eğer DB’i kendiniz tasarlıyor olsaydınız burada söylenecek çok şey olabilirdi fakat burada DB, MOSS tarafından oluşturulmaktadır ve sizin doğrudan bir müdahaleniz söz konusu değil, bu takdirde geriye sadece bazı konfigürasyon ve bakım mevzuları kalıyor. SQL Server üzerinde yapılan konfigürasyon ayarları ve bazı önerilerimi başka bir yazıyla sizinle paylaşacağım, konun fazla dağılmasını istemiyorum. Bu şartlar altında tamamen DB’e adanmış bir makine gerekmektedir, MOSS ve DB artık ayrı makinelerde. Aslında bakarsanız eğer sürdürebilirlik sizin için çok kritik değil ise bu mimari ile, makinelerin gücüne bağlı olarak çok ciddi projelerin altından kalkabilirsiniz. Donanım konfigürasyonlarıyla alakalı olarak, eğer bütçe kısıtlıysa ilk topolojide önerdiğim gibi 2 adet Core Duo, 2 GB Ram, 300-500 MB HDD bileşenlerinden oluşan bir desktop işinizi görecektir yada bütçenizi azıcık aşıp Workstation sunuculardan alabilirsiniz, uygun fiyata bir workstation bulmak mümkün. Burada tavsiyem eğer elinizdeki sunucular aynı değil ise iyi olanını DB için kullanın, örneğin toplam 6 GB ram’iniz varsa 2 GB ‘ı MOSS’un 4 GB’ı DB ‘nin olsun. Hep aynı şeyi söylüyorum ve yazı boyunca söyleyeceğim, DB’nin performansı önemli ve MS SQL Server sunucu kaynaklarını elinden geldiğince sömürür.. Bir sonraki adım; sürdürebilirlik ve performans (Medium Farm) Artık karar aşamasında değerlendirmeniz gereken bir çok parametre var. Sanırım tahmin ediyorsunuzdur, sunucu sayısı artacak maalesef, buda ekstra maliyet demektir. Sunucu sayılarının artması ekstra maliyet getirdiği gibi bakım ve yönetim işlerini de zorlaştırır. Fakat bir yandan talepler artmıştır ve bu kaçınılmaz olur. Öncelikle elimizde 3 sunucu var ise ne yapabiliriz ona bakalım. Alternatiflerimiz neler ? DB, Application Server, Web Front End Bu dizilim benim çok hoşuma giden bir dizilim değil açıkcası. Sistemde yine bir adanmış DB sunucusu, kullanıcıların doğrudan eriştiği Web Front End ve bazı servisleri çalıştırmak üzere Application sunucusu. Application sunucusu için şunu düşünebilirsiniz; MOSS’un bazı servisleri üzerinde koştuğu ISS servislerini yorar, örneğin Search servisi, eğer crawling işlemini WFE üzerinde yapacak olursanız bu işlem sunucu üzerinde ekstra bir yük oluşturur, çünkü search servisi sürekli sayfalara request’te bulunmakta ve hem DB’e hem de text dosyalarına write işlemi yapmaktadır, her neyse... Eğer siz bu sistemi sırf kurumsal arama için kurmadıysanız ben bu yapıyı önermeyeceğim. Failover Cluster, Web Front End DB, Application, WFE dizilimi (3 sunucu ile) maksimum performansı almak için en uygun mimari “olabilir” yalnız kurumlarda en önemli şey sadece performans değildir, sürdürebilirlik kavramı da önemlidir. Şirketler sistemin sürekli ayakta kalmasını isterler, eğer en önemli bileşenimiz DB ise onu sürekli ayakta tutmamız gerekiyor. Bunun için Microsoft’un önerdiği bir kaç metot var fakat en etkili olanı Failover Cluster yapısıdır. Burada sunucu yatırımınızı büyük oranda cluster yapıya harcamanız gerekiyor ve bu sunuculardan bir tanesi de sürekli pasif olarak bekleyecektir ta ki diğerinde bir problem oluşuncaya dek..(Bir hatırlatma, burada sadece bir tane SQL Server lisansı alırsınız çünkü her zaman sadece bir aktif sunucu vardır). Kişisel tecrübelerime göre eğer sağlam bir clsuter yapınız var ise gerçekten geceleri rahat uyuyabiliyorsunuz, eğer kurum içersinde ki kritik verileri yönetiyorsanız ve bu verilere 7/24 ulaşılabiliyor olması gerekiyorsa bu sizin için ciddi sıkıntı olabilir. Cluster yapıyı sadece bir sunucuda problem çıkması halinde kullanılabilir şeklinde düşünmeyin, bir çok güncelleme ve konfigürasyon ayarları sistemin restart edilmesini gerektiriyor, bir sunucunun restart edilmesi yaklaşık 5 dk ‘yı bulabilir, bu bile sizin başınızın ağrıması için yeterlidir, oysa Cluster mimaride bu 6-7 sn lere kadar inebiliyor.( Eğer vaktim olursa SQl Server Cluster mimarisiyle alakalı tecrübelerimi de sizinle paylaşacağım) DB, Web Font End Load Cluster Özel bir amacınız yok ise, DB sunucusunu tek bırakıp önde Load Balance Failover mimari kullanmak hiç akıllıca bir yöntem değildir. Bu alternatif üzerinde fazla durmuyorum. Sonraki adım.. Patronun yanına çıktınız ve artık dayanamayarak söylediniz, patron bu iş 3 sunucuyla olmuyor. Medium ve Large Farm dediğimiz yapılarda 4+ adet sunucu gerekir. Sırasıyla yapıları inceleyelim. En ideal-ekonomik (Failover SQL Custer & Load Balance WFE Cluster) En ideal yapı budur bence, tabi ki bu ihtiyaçlarınıza göre değişebilir, ama orta ve büyük ölçekli şirketlerde bu yapı çokça kullanılmakta ve başarılı olmaktadır. Şekilde de gördüğünüz gibi veri tabanı cluster şeklinde çalışmaktadır Daha önce söylediğimiz gibi sürdürebilirlilik için çok önemeli, öte yandan WFE sunucularının 2 tane olması hem performans hem de sürdürebilirlik için artı değerdir. Burada sizinde tahmin edebileceğiniz gibi WFE’lerden bir tanesinde bir problem çıktığında diğeri yol devam edecektir, aslında bunlar aktif-aktif çalışmaktadır ( Maalesef iki MOSS lisansı gerekiyor :) ). Öte yandan sistemde oluşabilecek ani yığılmalarda yükü aralarında paylaşacaklarından bu yapı performansı da artıracaktır. Burada bir sonraki adım sisteme ayrı bir App. sunucusu eklemektedir. Özellikle kurum içi aramalarda kullanılan MOSS Search Service çalıştığı makineyi zorlar, eğer sistemin sürekli crawl etmesini istiyorsanız bu performans problemlerine yol açabilir, bu takdir bu iş için adanmış bir sunucuya ihtiyaç olacaktır. Peki bu iş nereye kadar devam eder. Burada High-End sunucular üzerinde DB konumlandırılıp onlarca WFE leri farklı amaçlar için kullanabilirsiniz, aynı şekilde search için yapacaklarınızda bu mimariyi değiştirebilir. Ben search kısmıyla alakalı daha detaylı bilgi vereceğim ve search yapılandırmasıyla alakalı detaylara orada gireceğim. Dediğim gibi bu bilgiler size kara aşamasında bir fikir verecektir ama uygulamanın kapsamına göre farklı mimarilerde söz konusu olabilir.