Bu yazımda IIS 7.0 uygulama havuzlarındaki (application pools) yeniliklerden bahsedeceğim. Daha önce bahsettiğim özellikler kadar göz önünde olmasalarda, burada bahsedeceğim özellikler, eminim ki IIS 7.0'a geçmek için çok geçerli nedenler sağlayacaktır.

Uygulama Havuzları

IIS 6.0 (yani Windows 2003) ile gelen uygulama havuzu mantığı, bana göre, IIS açısından ciddi bir devrim olarak nitelenebilecek kadar önemli bir yenilikti. Temel mantık, web uygulamalarımızın işlendiği "process"leri bizim kontrol edebilme ve yönetebilmemiz üzerine kurulmuştu. Her bir havuzun ne sıklıkla yeniden başlatılacağından, hangi kullanıcı yetkileriyle çalışacağına kadar pek çok ayarı yapabiliyoruz. Ayrıca her bir havuz üzerinde çalışacak uygulamalara da biz karar verip, istediğimiz sayıda havuz yaratabiliyoruz.

Bu noktada bir ara not vermek istiyorum: IIS 6.0 veya 7.0'da yaratabileceğimiz havuz sayısı teorik olarak neredeyse sınırsızdır. Ancak elbette işletim sistemi ve donanımımızın kısıtlamaları olacaktır. Bununla ilgili şunu söyleyebilirim, yeterli donanımla 500'den uygulama havuzunun başarılı bir şekilde çalıştırıldığını gördüm.

IIS 6.0'daki bazı kısıtlamalar

IIS 6.0'da çokca şikayet edilen birkaç tane kısıtlama vardı. Bunların ne olduklarına ve IIS 7.0'de nasıl giderildiklerine bir göz atalım:

• IIS 6.0'ı, eğer 64bit bir makinede kurulu ise, istersek 64bit olarak, istersek de 32bit olarak çalıştırabiliyorduk. Bunu Metabase'deki "Enable32BitAppOnWin64" parametresi ile belirleyebiliyorduk. Ancak bu parametre sadece web sunucu seviyesinde tanımlanabiliyordu. Yani, IIS, ya tamamen 64bit çalışıyordu, ya da tamamen 32bit. Örneğin, 64bit bir sunucu üzerinde hem ASP.NET 1.1, hem de ASP.NET 2.0 uygulamaları çalıştırmak istediğimizde, ASP.NET 1.1'in 64bit versiyonu olmadığından, tüm uygulamalarımızı 32bit çalıştırmak zorundayız.
  
  IIS 7.0'da, bu özellik artık uygulama havuzu seviyesinde tanımlanabiliyor. Yani aynı sunucu üzerinde bazı uygulamaları 64bit olarak, bazılarını 32bit olarak çalıştırma şansımız bulunuyor.
  
  
• IIS 6.0'da, herhangi bir ASP.NET uygulamasının versiyonunu, uygulama üzerinde tanımlayabiliyoruz. Ancak, aynı uygulama havuzu üzerinde hem 1.1 hem 2.0 uygulamalar çalıştıramayız. Buna, uygulamaları ve üzerinde çalışakları havuzları tanımlarken bizim dikkat etmemiz gerekiyor.
  
  IIS 7.0'da ise, bu tanımı da uygulama havuzu seviyesinde yapıyoruz. Bu da olası sorunları en aza indirmemize yardımcı oluyor.
  
  
• IIS 6.0'ın, "IIS 5.0 Isolation Mode" isimli bir çalışma modu bulunuyor. Bu, adından da anlaşılabileceği gibi, IIS'in tam olarak 5.0 gibi çalışmasını sağlıyor. Hatırlayacağınız gibi, IIS 5.0'da uygulama havuzlar yoktu; mimari olarak tamamen farklıydı. Bu yüzden, IIS üzerinde bu modu açtığımızda IIS tamamiyle 5.0 gibi çalışacaktır. Yani hem uygulama havuzlarımız olsun, hem de bazı uygulamalar "IIS 5.0 Isolation Mode"da çalışsın deme şansımız bulunmuyor.
  
  IIS 7.0'da da, IIS 6.0 gibi çalışma seçeneğimiz bulunuyor. Ve bunu uygulama havuzu seviyesinde tanımlayabiliyoruz. Her uygulama havuzunun "Managed Pipeline Mode" isimli bir özelliği bulunuyor. Bunu "integrated" seçersek, o havuz IIS 7.0'la gelen "integrated pipeline" modunda çalışacaktır. Eğer bu ayarın alabileceği diğer değer de "classic"dir. Bu modu, IIS 6.0 modu gibi düşünmek yanlış olmaz. Yukarıda da söylediğim gibi, bu ayar da uygulama havuzu seviyesinde yapılan bir ayardır.
  

Yukarıdaki değişiklik ve yeniliklerin dışında, bir de daha önce grafik arayüzden yapamadığımız ayarlar var. Herhangi bir uygulama havuzunun "gelişmiş özellikler"ini (Advanced settings) açtığınızda, IIS 6.0'dakinden çok daha fazla özellik göreceksiniz. Bunların çoğu aslında IIS 6.0'da da ayarlayabildiğimiz özelliklerdi. Ancak bunları arayüzden yapamıyorduk. Özel olarak varlıklarını bilmemiz ve bunu metabase içerisinde tanımlamamız gerekiyordu. Bunlara birkaç örnek vermek gerekirse:

• LoadBalancerCapabilities: "Service Unavailable" hatası dönülmesi gereken durumlarda bunun ne şekilde yapılacağı ayarıdır. "Load balancer" kullandığımız durumlarda, onun desteklediği seviyeye göre ayar yapabiliriz.
• logEventOnRecycle: IIS, bir uygulama havuzu bazı nedenlerle yeniden başlatıldığında olay günlüklerine (event logs) bununla ilgili bir kayıt düşer. Hangi nedenlerle yeniden başlatıldığında kayıt düşülmesini istediğimizi bu parametre ile ayarlıyoruz.
• orphanWorkerProcess: IIS 6.0 ve 7.0'da, bir "worker process", yanıt veremez duruma gelirse, o kapatılıp yerine yenisi açılır. Eğer biz, o "worker process"in neden cevap veremediğini araştırmak istersek, o "process" kapatılmadan yenisi açılsın şeklinde bir tanımlama yapabiliriz.

SONUÇ

Bugüne kadar IIS 7.0 hakkında yazdığım yazılarda, yeni ve geliştirilmiş özelliklerden bazılarına değinmeye çalıştım. Bunları anlatırken önceliği faydalı olacağını düşündüğüm ve verdiğim eğitimlerde beğenildiğini gördüğüm özelliklere verdim. Ancak bu 3 yazımda bahsettiklerim toplamda IIS 7.0'nin yeni ve faydalı özelliklerinin yine de küçük bir kısmıdır. Benim naçizane önerim, en kısa zamanda IIS 7.0 ile testlere başlamanız ve en kısa zamanda uygulamalarınızı taşımanız olacaktır. Her ne kadar biraz reklam kokan bir cümle de olsa, şahsen ben pişman olacağınızı düşünmüyorum.

CENK ISCAN