Azure RDS Deep Dive makale serisinin ilk bölümünde makale serisi içinde gerçekleştirecek olduğumuz işlemlerin tanıtımı, kurum içi datacentermiz içinde konumlandırdığımız RDS ortamı ile Azure içinde oluşturacak olduğumuz RDS ortamı arasında ki farkları, Azure üzerinde konumlandıracak olduğumuz RDS ortamının Kurum Data Centerimiz içinde bulunan RDS ortamına göre eksileri-artıları nelerdir bunları paylaşacağız.
Azure RDS Deep Dive makale serisinde referans aldığım kaynaklar
Azure Desktop Hosting – Reference Architecture and Deployment Guides ve Microsoft Virtual Academy üzerinde bulunan Remote Desktop Services on Microsoft Azure Deep Dive eğitim içeriğidir. Bu kaynaklardan edinmiş olduğum bilgiler ve sahip olduğum tecrübeler ile bu makale serisi hazırlanmış ve özelleştirilmiş.
Makale serisi içinde paylaşılacak olan bilgiler Level200 – Level400 arasındadır. Öncelikle şunu belirtmek isterim, Azure RDS Deep Dive Makale serisini okumaya başlamadan önce portalımız üzerinde daha önce paylaşmış olduğum aşağıdaki makale ve makale serilerini okumanızı önermekteyim!
Bu makale serisi tamamlandıktan sonra Azure RDS Deep Dive etiketi ile portalımız üzerinden hızlı erişim gerçekleştirebileksiniz.
Biliyorum, bu makale serilerini okumak uzun bir vaktinizi alacaktır ama şunu belirtmeliyim ki Azure RDS Deep Dive makale serisi içinde gerçekleştirilen adımların bir çoğunda bu makale serisi içindeki ilgili bölümler referans gösterilektir.
Örnek, RDWeb Access Rolü için sertifika nasıl oluşturulur, sertifika seçimi nelerdir gibi bilgiler bu makale serisi içinde paylaşılmayacaktır! Daha önce paylaşılan makale serilerinin içindeki ilgili makalelere yönlendirileceksiniz.
Kısaca, Azure RDS Deep Dive Makale serisi için temel ön gereksinim, On-premise olarak tanımladığımız kurum içi Data Centerimiz içinde bulunan RDS ortamına hakim olduğunuz beklenilmektedir.
Ben makale serisini hazırlarken, sizlerde daha önce yayınlamış olduğum makale serilerime göz atabilirsiniz.
-
Remote Desktop Services Yüksek Erişilebilirlik Çözümleri Makale Serisi (18 Bölüm)
-
RemoteApp Deneyimleri Makale Serisi (17 Bölüm)
-
Virtual Machine Manager 2012 SP1 Network Yapılandırması (7 Bölüm)
RDS Ortamımızı Niçin Azure içinde konumlandırmalıyız ?
Bu sorunun cevabı aslında çok basit. Azure’ nin bizlere sağlamış olduğu bütün nimetleri RDS ortamı için kullanabilmekteyiz. RDS ortamı için ihtiyaç duymuş olduğumuz bileşenler (network bileşenleri, storage, sunucu, iş süreklilik bileşenleri vb…) sıfırdan almak yerine, hazır bir datacenter içinde yani Azure’ den kiralayabiliriz ve RDS için özel yapılandırılmış teknolojilerden yararlanabiliriz.
Ölçeklendirme, Yatay büyüme ve Dikey büyüme avantajları.
Kurumumuz için ihtiyaç duymuş olduğumuz RDS bileşenleri için testler, hesaplama araçları, referans kaynaklar vb… bir çok bileşen kullandık ve kusursuz bir kapasite planı hazırladık. En doğru şekilde gerçekleştirilen kapasite planında bile ufak bir sapma değeri bulunmaktadır. Bu sapma oranları değerlendirilerek alımlar gerçekleştirilir ve projeye başlanılır. Fakat bu değerlerin, planlamış olduğumuz, kabul edilebilir sapma oranının dışına çıkması çok fazla görülen olaylardır. Örnek olarak Kurumumuzun beklenmedik bir şekilde büyümesi-küçülmesi bu sapmaları etkileyecek faktörlerdir.
Azure bu gibi ihtiyaçlarda bizlere büyük kolaylıklar sunmakta ve Yatay büyüme – Dikey büyüme seçenekleri ile herhangi bir kesinti ve telafi edilebilir planlı kesintiler ile büyümeyi gerçekleştirme şansı vermekte ve projemizde elimizi kolaylaştırmaktadır. Ve en önemlisi, bizler ihtiyaçlarımıza göre büyüme-küçülme gerçekleştirirken kullandığımız kadar ödemekteyiz.
Dikey Büyüme, projeye başlamış olduğumuz zaman diliminde X kullanıcıya hizmet edecek sunucu kaynağını Azure üzerinden kiralamış olabiliriz. Fakat planlamış olduğumuz zaman dilimi içinde beklenmedik bir büyüme gerçekleşti ve mevcut kiralamış olduğumuz kaynaklar artık bizler için yeterli durumda değil. Projeye başlamış olduğumuz zamanda Large VM’i ihtiyaç durumundaydı ve bizler yenilenen ihtiyaçlarla Extra Large olarak değişim yapabiliriz ve bu değişime Dikey büyüme demekteyiz.
Dikey büyümeye on-premisede ki sunucularımıza göre benzetme yapmamız gerekirse 4 Cpu desteği bulunan bir fiziksel sunucu üzernde 2 Cpu ile projeye başlıyoruz ve ihtiyaç durumunda bu fiziksel sunucuya ilave 2 Cpu daha takıp, slotları tamamen dolduruyoruz ve bu şekilde fiziksel sunucumuzun cpu kaynaklarını tamamen kullanıyoruz. Biz buna dikey büyüme demekteyiz ve benzer bir durum Azure üzerinde bulunmaktadır.
Change the Size of a Windows Azure Virtual Machine makalesi ile bu konu hakkında detaylı bilgiye sahip olabilirsiniz.
Yatay büyüme, Projemize 4 cpu desteği bulunan bir sunucunun 2 cpu sunu kullanarak başladık. Zaman içnde mevcut kaynaklar bize yeterli gelmedi ve dikey büyüme çözümü ile ilave 2 cpu daha taktık 4 cpu ile yaşamaya devam ettik. Ve zaman içinde 4 cpu lu sunucumuzun sahip olduğumuz ihtiyaçlara cevap vermediğini gördük.
Şimdi sıra yatay büyümeye geldi. Mevcut kaynakların yanına, yeni keynaklar ekleyip beraber çalışmasını sağlama işlemine yatay büyüme demekteyiz.
Azure RDS Deep Dive Makale serisi için hazırlamış olduğum topoloji içinde yatay büyüme gerçekleştirilen sunucuları yukarıda görebilmektesiniz. Topoloji içinde kırmızı ok ile göstermiş olduğum sunucuların başlarında mavi renkli kutular, bu sunucuların yatay büyüdüğünü, aynı rol ve servislere sahip sunucular olduğunu ve aynı hizmet için yapılandırıldığı anlamına gelmektedir.
Yatay büyüme – Dikey büyüme ile ilgili seçimleri gerçekleştirirken ihtiyaçlarımızı ve bu ihtiyaç sonrasında bir seçim yaparken bize getirecek olduğu maaliyetleri doğru hesaplamamız gerekmektedir.
Örnek vermemiz gerekirse 4 cpu ya sahip tek bir sunucu ile 2 adet iki cpu ya sahip iki sunucunun her zaman aynı performansta olmadığı, yatay büyüme gerçekleştirilen iki farklı sunucuya paylaştırılan iş yüklerinin daha hızlı çalıştığı Amdahl Yasası ile kanıtlanmıştır.
Elbetteki yatay büyümeler, dikey büyümelere göre daha maaliyetli olan çözümlerdir. Bu noktada seçim yaparken ihtiyaçları doğru analiz etmemiz gerekmektedir.
İş Sürekliliği yatay büyüme gerçekleştirmek her zaman için daha maaliyetlidir. Bunun nedeni aynı işi yapacak olan birden fazla kaynağın yapılandırılmasıdır. Bu noktada performans kazanımı ile birlikte iş sürekliliğinide kazanıyoruz ve tek nokta hatasından kurtuluyoruz. Sonuçta aynı işlemi gerçekleştiren birden fazla sunucuya sahip oluyoruz.
Azure tarafında iş sürekliliğini yatay büyüme ile gerçekleştirebileceğimiz gibi çok basit bir seçim ile Availability Set yapılandırılması gerçekleştirerek, iş sürekliliğini ve otomatik ölçeklendirme (Cloud Services Scale) özelliğinide ekleyebimekteyiz.
Azure Sanal Sunucularımızı Availability Set olarak yapılandırdığımız zaman aynı rollere sahip sunucumuzun, farklı Azure Kabinleri içinde barınmasını ve kabin bazlı hatalardan ve aynı zamanda güncelleştirme zamanlarında oluşan kesintilerden etkilenmemesini sağlayabilmekteyiz.
Azure Sanal sunucumuzun barınmış olduğu kabin arızalı duruma geldiği zaman diğer kabin içinde bulunan sanal sunucu SLA kapsamında, hizmet kesintisi olmadan hizmet etmeye devam edecektir. Yaşanılacak arızanın haricinde ihtiyaç duymuş olduğumuz güncelleştirmeler içinde Availability Set’ in büyük bir önemi bulunmaktadır. Availability Set olarak yapılandırmış olduğumuz bir Azure Sanal sunucumuzun güncelleştirmeleri, sıralı bir şekilde yapılacağı için kesintiden etkilenmeyeceğiz.
Availability Set yapılandırılması SLA anlaşmamızıda etkilemektedir. Availability Set yapılandırılmamış bir sunucu için SLA süresi bulunmamaktadır!
Yaşanılacak bir arıza durumunda Microsoft’ un bizlere vermiş olduğu söz Best Efor’ dur yani “en kısa sürede tekrardan hizmet etmesini sağlayacağız” derler ve süre vermezler. Fakat Availability Set seçimini gerçekleştirdikten sonra Microsoft’ un bizlere sunmuş olduğu SLA değeri %99.95 Up-time dir.
Bu bilgileri paylaştıktan sonra makale içindeki topolojimizde ilgili bölümü gösterelim. Azure RDS Deep Dive makale serimiz kendi içinde iki bölümden oluşmaktadır. Basic RDS Deployment ve Extended RDS Deployment.
Basic RDS Deployment bölümünde Azure Sanal sunucularımızı Cloud1 içinde Availability Set yapılandırmadan hizmet ettireceğiz ve Clous Services yapılandırması ile birlikte Availability Set’i inceleyeceğiz. Cloud1 içinde bulunacak olan RDGW/RDWA sunucularımız, aynı rol ve aynı servislere sahip durumda olacak ve birden fazla sunucu üzerinde hizmet edecekler. Yani Cloud1 içinde önce dikey sonra Yatay büyümeyi gerçekleştirirken Cloud2 içinde Dikey büyümeyi gerçekleştireceğiz ve Cloud2 içinde bulunan RDGW/RDWA sunucumuz tek bir tane olduğu için bu sunucumuzu Availability Set olarak yapılandıracağız.
Topoloji içindeki ilgili sunucuların görüntülerini yukarıda görebilirsiniz. Yatay büyümeye sahip Cloud 1 içinde ki sunucularımız yeşil ok ile gösterilmişken Cloud2 içinde bulunan dikey büyüme yapılacak sunucumuz mavi çizgiler ile (Availability Set sembolüdür) ve kırmızı ok ile gösterilmiştir.
Cloud1 içinde bulunan RDGW/RDWA sunucuların iş sürekliliği ile Cloud2 içinde bulunan RDGW/RDWA sunucu rolü iş sürekliliğindede farklılık bulunmaktadır. Bu fark işletim sistemindeki iş süreklilik farkıdır.
Cloud1 içinde aynı amaca hizmet eden birden fazla sunucu varken bu sunucuların sahip olduğu OS bazlı bir hatada (OS in bozulması, servisin kesilmesi, kötü amaçlı yazılımın hizmet kesintisi yapması vb…) bizler küme içinde bulunan diğer sunucu üzerinden sistemin hizmet etmesini sağlarken Cloud2 içinde yapılandırılan RDGW/RDWA rolüne sahip sunucumuzda bu mümkün değildir.
Azure RDS Deep Dive makale serisimizin ilk bölümü Azure RDS Overview ile makale serisine giriş yaptık, kaynakları gösterdik ve Azure üzerinde niçin RDS’ i konumlandırmalıyız sorusuna Azure Infrastructure Services içinde bulunan Hypervisor seviyesinde cevaplar vermeye çalıştık. RDS platformunu Azure üzerinde konumlandırmamız için verecek olduğumuz diğer cevaplar Infrastructure Services içinde bulunan Network ve Storage bölümleridir ve bu bölümlerdeki avantajları makale serimizin ilgili bölümlerinde detaylı olarak paylaşacağız.