Citrix Virtual Apps and Desktops Deployment Senaryoları – 1

Selamlar, Citrix Virtual Apps and Desktops Deployment Senaryoları serisine en sık kullanılan deployment modeli olan On-Premise Deployment ile başlıyorum. Aşağıdaki referans mimari üzerinden ilerleyerek neden böyle bir topoloji çıkarıldığını, nelere dikkat edilmesi gerektiğinden bahsedeceğim.

Citrix On-Premises Referans Mimari

Her şey kullanıcının sisteme erişmek için kullandığı cihaz ile başlar, buna yeni nesil Akıllı TV’ler de dahil bütün cihazlarla CVAD ortamına erişip çalışabilmek mümkün. Topolojide kullanılan Citrix Bileşenleri;

1. Citrix Gateway (Citrix Networking ailesinden ADC/Netscaler)
2. Citrix Storefront (Kullanıcıların ortamlarına erişmek için kullandığı IIS Web Server)
3. Citrix Desktop Delivery Controller (Bütün bir ortamın yönetildiği, kararların verildiği Management Console)
4. MSSQL Database (Site hakkındaki bütün bilgilerin tutulduğu, 3 collationdan oluşan -monitoring, logging ve site- database server)
5. Citrix Studio (Citrix bileşenlerini kullanmak için -Networking ailesi hariç- gerekli MMC tabanlı Management Yazılımı)
6. Citrix License Server (Adından da anlaşılacağı üzere lisans yönetiminin yapıldığı Web Server)
7. Citrix Director (Bütün bi ortamı izleyebileceğiniz, gerektiğinde Remote Support amaçlı olarak kullanabileceğiniz, Uygulama ve Desktopların performans raporlamasını yapabildiğiniz, Troubleshooting için önemli role sahip ve hatta belirli kurallar girerek Alerts oluşturabileceğiniz Web Server)
8. Back-end Resources (Clone VM’lerin ve Sanallaştırılmış Uygulamaların barındırıldığı server katmanı)
9. Host (Aslında her şeyin başladığı nokta olan fiziksel sunucuların üzerine kurulan Hypervisor katmanı, bütün Hypervisor Yazılımları ile uyumlu çalışan tek VDI çözümüdür)

Artık diyagramdaki her bileşenin temelde ne işe yaradığını biliyoruz. Şimdi bu diyagrama göre bir senaryo oluşturalım. 

Citrix User Profile Management

Citrix’in Best Practices olarak vurguladığı konulardan bir tanesi de deployment öncesi ihtiyaçları tespit etmektir. Şöyle bir örnek tablo oluşturabiliriz;

Örnek Kullanıcı Profilleri

Burada tek tek kullanıcı gruplarını açıklamak yerine, önerdiğim çözümler ve gerekçeleri ile başlayalım;

Muhasebeciler

Profil yönetimine kesinlikle ihtiyaç duyan bir gruptur. Bunun sebebi, sürekli olarak Desktop ve My Documents üzerinde; mail ekleri, kaydedilen MS Office dosyaları ve kullandıkları Finans yazılımları dosyaları bulundurmalarıdır. Bu dosyaları VM üzerindeki diskte kaydetmek yerine bir Windows File Server adreslediğimizde hem Non-Persistent with Profile Management yapısını sağlamış oluyoruz, hem de VM’ler üzerinde gereksiz disk kullanımının önüne geçiyoruz.

Yöneticiler 

Statik makine verilirken iki yol çizmemiz gerekir; VM local disk üzerinde dosya tutmayan ve tutan olarak. Burada VM local disk üzerinde dosya tutacak şekilde provision yaparsak, bu makinelere Catalog Update denilen havuzdaki VM’lerin aynı anda güncellenmesi senaryosunu uygulayamayız. Lakin, bazı yönetici gruplarında edindiğim bilgi doğrultusunda şöyle istekler gelmişti “Kullandığım makinenin FQDN’i özel izinlere ve lisanslamalara sahip, bu yüzden her zaman aynı makinede çalışmalıyım” bu yüzden her zaman kullanıcıyı aynı VM’e erişecek şekilde konfigüre ediyoruz ama VM local diskte dosya tutmayıp, bunu da yine File Server’daki Profile Management klasörümüze depoluyoruz.

Grafik Tasarımcılar 

Power Users olarak geçen bir gruptur, VM havuzundan bağlanacakları herhangi bir makinede çalışabilirler. Genelde bu grubun kullandığı makineler üzerinde NVIDIA GPU Profilleri oluşturulduğu için, nish bi gruptur. Local diskte dosya tutmaya ihtiyaçları olmaz, File Server’da dosyaları tutulsa yeterlidir. Sadece burada şöyle bi detay var; Citrix’de Session Sync özelliğinin aktif edilmesi gerekiyor. Kullanıcı notebook üzerinde çalışırken, bi anda notebook’u bırakıp tabletten çalışmaya devam etmek isteyebilir.

Müşteri Temsilcileri 

Task Workers olarak geçen bir gruptur. Kullandıkları spesifik birkaç uygulama haricinde herhangi bir şeye ihtiyaç duymazlar. Profil yönetimi bu grup için tercihe bağlıdır, olmasa da olur denilen senaryolar mevcuttur. Genelde bütün işlerini Web üzerinden veya localde kullanılan yazılımlar üzerinde tamamlarlar. 

Citrix On-Premises Referans Mimari Detaylı Bakış

Yukarıdaki topolojiyi referans aldığımızda ve en sık kullanılanın o olduğu göz önünde bulundurulursa Citrix Mimarisinin 5 katmandan oluşan bir yapı olduğunu söyleyebiliriz. Kullanıcı, erişim, yönetim, kaynak ve host katmanları. Şimdi bu katmanları inceleyelim;

Kullanıcılar (Users)

Amaç kullanıcının herhangi bir cihaz üzerinden erişebiliyor olmasıdır. Eğer internal network bir yapı ise bu cihazların şirket networkünde olması, VPN kullanılıyorsa vpn konfigürasyonunun yapılmış olması veya arada bir Citrix Gateway varsa SSL ile gelebiliyor olması gerekmektedir. Bu senaryoda bir Gateway kullanılmış. Bunun sebebi kullanıcıların güvenli olmayan bir networkden eriştikleri durumda arada micro-VPN katmanı olduğu için session üzerinde herhangi bir güvenlik açığı oluşmamasıdır. Buna ek olarak, dışarıdan erişilmesi gereken durumlarda Gateway, VPN’e göre daha gelişmiş ve güvenli bir çözümdür. Kullanılan Wildcard SSL ve Citrix ADC’nin Linux altyapısına sahip olmasıdır. Bağlantı her zaman şifrelenir, bilinen bütün ataklarda içinse güvenlik duvarı rolü üstlenir.

Erişim (Access)

Kullanıcı isteklerinin karşılandığı katmandır. Burada Gateway ve Storefront bulunur. Storefront, Citrix’in uygulama ve masaüstü dağıtımını yaptığı IIS Web Serverdır. Normal şartlarda Internal Network’de çalışan Storefront, Citrix Gateway sayesinde External bağlantılara da cevap verebilir duruma gelir. Bunu da Gateway’in bahsettiğim micro-VPN özelliği sayesinde gerçekleştirir. Kullanıcı cihazında hiçbir Agent türevi bir şeye (Citrix Workspace hariç) ihtiyaç duymadan direkt görüntüleme sağlar. Bunu ister Citrix’in Workspace uygulaması ile isterseniz HTML5 desteği ile sağlayabilirsiniz. Burada dikkat edilmesi gereken konu ise Gateway’in konumlandırıldığı yerdir, Best Practices olarak DMZ ortamına konumlandırılması önerilir. DMZ’in olmadığı yerde ise Firewall’un arkasına konumlandırılır. İstekler önce Firewall’a gelir, çözmesi gereken DNS adresi göz önünde bulundurularak Gateway’in Virtual IP adresine bir 443 NAT kuralı oluşturularak tamamlanmış olur. Gateway’in arkasında da Storefront çalıştığı için Active Directory LDAP Authentication, MFA vb. her şeyin Gateway konsolunda konfigüre edilmiş olması gerekir ki Domain kullanıcıları Storefront’a giriş yapabilsin, sonrasında aslında local networkde çalışan makinelerine erişebilsinler. Buna ek olarak Gateway ürünü Storefront-Native çalıştığı için Session Performance olarak %20-30 civarında bir artış sağlamaktadır. Ayrıca üzerindeki yük dengeleme özelliğini de kullanarak daha dengeli bir yapı elde edilebilir. Hatta AAA Groups özelliği ile kullanıcıların Group bazlı olarak erişimlerini sağlayabilir/denetleyebiliriz.

Yönetim (Control)

Citrix yapısının CEO’su olan Desktop Delivery Controller bu katmandadır. Back-end resources ve Storefront arasındaki haberleşmeyi sağlayarak, Database üzerinde yazdığı bilgileri göz önünde bulundurup kullanıcıya atanmış olan her ne ise onu ulaştırır. Citrix ortamına dair bütün kısıtlamalar bu Role üzerinde gerçekleştirilir. Klonlanacak makineler, dağıtılacak uygulamalar, kullanıcı grupları, uygulama grupları; kullanıcı deneyimi, güvenliği ve çevre birimleri ile ilgili bütün konfigürasyonlar bunun üzerinde sonlanır. Bu Role’e bağlı bazı bileşenler vardır. Citrix Studio, MMC tabanlı bir yönetim konsoludur. Citrix Director, bütün bir yapıyı izleyebilen, raporlayabilen, uyarılar oluşturabilen, yeri geldiğinde Windows Remote Assistance özelliği sayesinde Remote Support sağlayabilen bir bileşendir. HTML5 arayüzü olan basit bir monitoring tool gibi görünse de, aslında yukarıda saydığım kabiliyetlere sahip güçlü bir bileşendir. IT Adminlerinin gözü kulağı eli ayağıdır. License server, lisans yönetiminin yapıldığı Web arayüzüdür.

Buradaki önemli bir diğer Role ise, Citrix’e ait olmayan MSSQL Serverdır. Üzerinde üç adet Citrix’e ait database bulundurur; Monitoring, Logging ve Site’dır. Bu veritabanları üzerine yazılan bilgiler sayesinde Desktop Delivery Controller nerede neyi yaptığını bilir. Citrix ile ilgili bir backup planı oluşturulacaksa en başa Database Server’ı ekleyin. Bir kural, Citrix’den başka hiçbir database bulunmamalıdır üzerinde. HA için, Mirroring, Always-on Availability veya Failover Clustering yapılabilir. Genelde lisans maliyetlerinden dolayı SQL Standard kullanıldığından Mirroring yöntemi kullanılır.

Kaynak (Back-end Resources) 

Uygulamaların ve masaüstlerinin tutulduğu host üzerindeki ayrılmış alandır. Citrix Broker Service aracılığıyla buradaki VM’ler Desktop Delivery Controller ile haberleşir ve Authentication tamamlanır. Thin Provisioned olarak oluşturulması önerilen VM’ler bu katmanda bulunur. Management yapısıyla Any-to-Any haberleşmesi gerekmektedir. Citrix’in resmi sitesindeki Communication Portlar aktif edilse dahi, ileride oluşacak bir Troubleshooting senaryosunda Event Viewer ve Director arasında gidip gelmek size kendinizi kötü hissettirecektir, bu yüzden Any-to-Any önerilir. Güvenlik gerekçeleri öne sürülerek böyle bi kural reddedilirse yapılacak şey Citrix’e özel iki ayrı VLAN oluşturulmasıdır.

Host (Hypervisor ve Fiziksel Sunucu)

Citrix, hypervisor-agnostik çalışan bir yapıya sahiptir. Bütün üreticiler ile uyumlu çalışır. Sadece XenServer kullanıldığında ek bi özellik gelir, o da PVS Accelerator’dır. Network-level boot metodu olduğu için CVAD üzerindeki klonların oluşturacağı Network trafiği azaltır. Nutanix’e ait Acropolis ise Provisioning hızını %30’a kadar artırır ve buna ek olarak Catalog Update (Master Image güncellemesi) gibi operasyonel işler yine aynı şekilde diğer Hypervisorlara göre daha hızlı gerçekleşir.

Fiziksel sunucu bana göre her şeyin başladığı yerdir. Hangi VDI çözümünü kullanırsanız kullanın, alttaki fiziksel sunucu iyi değilse o çözümden alacağınız verim de aynı seviyede olur. Bu yüzden özellikle boot göz önünde bulundurulduğunda PVS ise en az 10gbit network altyapısı, MCS ise makine başına en az 150 IOPS verebileceğiniz, Boot Storm yaşatmayacak bir Storage yapısına sahip olunması gerekir. Tabii ki buna ek olarak iyi bir CPU ve RAM gerekmektedir. Bunlara sahipseniz, üzerinde hangi Hypervisor’ı konumlandırırsanız konumlandırın, zaten yüksek performans alırsınız. İşin gerçeği bu. Yalnızca şöyle bir istisna var, Hyperconverge mimari kullanıyorsanız VSAN (VMware’e ait bir çözüm) ve AHV (Acropolis Hypervisor) diskleriniz eski dahi olsa ciddi performans artışı sağlamaktadır. Tecrübeyle sabit bilgi.

Okuduğunuz için teşekkürler.