معماری Horizon – قسمت چهارم

• 22 خرداد |
• مهسا محمودی راد |
• مجازی سازی(Virtualization)

Remote Agents

در حال حاضر Horizon پیاده‌سازی Horizon Agent  است که در یک مکان دور  (Remote) ازHorizon Connection Servers پشتیبانی می‌شود. این کار زمانی مفید است که در داخل دیتاسنتر یا  cloud platform  گنجایش یاCapacity  را داشته باشید و همینطور یکHorizon Pod  نداشته باشید. معیاری که برای این ویژگی توصیه شده، بالاتر از 1000 VMs در یک موقعیت مکانی  Remote است. اگرچه این ویژگی با تعداد بالاتر از حدی که توصیه شده است هنوزکار می‌کند، اما این تعداد به اندازه‌ای بزرگ می‌شود که شما مجبور می‌شوید آنها را در یکHorizon pod  جداگانه در پلتفورم ابری جایگزین کنید.

ایجاد شبکه‌سازی (Networking) و مسیریابی (Routing) بین محیط Horizon  فعلی و مکانی که قرار است ظرفیت منابع را مصرف کند و در آن Remote Agent  نصب می‌شود، مورد نیاز است. یکی از محدودیت‌‌های فنی که باید Horizon Agents از آن آگاه باشد (در داخل virtual desktops و RDSH hosts اجرا شوند) این است که باید در 120 میلی‌ثانیه تأخیر Horizon Connection Server باشند.

 دو مورد رایج استفاده از این ویژگی عبارتند از:

• ویژگی اول Centralize Horizon Pods for Private Datacenters – تعداد Horizon pod ها را از چندین مکان و مراکز داده خصوصی به حداقل برسانید. این کار زمانی مفید است که virtual desktopها نیاز به حضور فیزیکی در چندین مکان مانند دفاتر شعبه دارند. به طور معمول، این امر نیازمند podهای جداگانه در هر مکان است، اما با remote agent architecture، زیرساخت مدیریتی را می‌توان متمرکز کرد و تعداد پادهایی را که باید پیاده‌سازی شوند را کاهش داد.
• ویژگی دوم Extend an existing Horizon pod to consume capacity from a cloud platform – Existing Horizon pods های موجود می‌توانند مدیریت و مصرف Capacity پیاده‌سازی شده در Cloud  را گسترش دهند.

متمرکز کردن Horizon Pods  برروی  Private Datacenters 

اگرHorizon desktop  ها و RDS host ها در چندین مکان قرار گرفته شوند، به جای پیاده‌سازی و مدیریت یک Horizon pod مجزا، در کنار ظرفیت virtual desktop / RDSH در هر مکان این ویژگی اجازه می‌دهد تا تعداد  podهایی که در مرکز قرار دارند را کاهش دهد. به این منظور، این ویژگی در هر نسخه پشتیبانی شده در حال حاضر ۸ x و افق ۷ x استفاده می‌شود.  برای این مورد، این ویژگی برای هر نسخه‌ای ازHorizon  که در حال حاضر پشتیبانی می‌شود، اعمال می‌شود. (.  Horizon 8 . x and Horizon 7 . x)

گسترش Horizon Pod در Consume Cloud Capacity

در این سناریو،  Horizon podهای موجود، که معمولاً در private data center پیاده‌سازی ‌می‌شوند، می‌توانند بدون نیاز به ایجاد و مدیریت‌کردن یکHorizon Pod  جدید در cloud platform به Public cloud،  burst کنند. این امر امکان گسترشHorizon Pod  های موجود را می‌دهد تا cloud capacity را در یکی از cloud Platform های پشتیبانی شده مدیریت و استفاده کند، مانند   VMware Cloud on AWS،Azure VMware Solution (AVS) ، Google Cloud VMware Engine (GCVE) ،  Oracle Cloud VMware Solution (OCVS)، یا VMware Cloud on Dell EMC .

برای افزایشcloud capacity  به یکHorizon Pod  موجود به موارد زیر توجه فرمایید:

1. از cloud subscriptionخود استفاده کنید و یک software defined datacenter (SDDC) جدید بر روی cloud platform مورد نظر با تعداد Host های مورد نظر ایجاد کنید.
2. شبکة بین datacenter که میزبان Horizon pod موجود و cloud data center مورد نظر است را پیاده‌سازی کنید و اطمینان حاصل کنید که تأخیر آن، 120 میلی‌ثانیه یا کمتر است.
3. vCenter (SDDC) تازه ایجاد شده را به Horizon pod موجود اضافه کنید.
4. Horizon pod می‌تواند مدیریت cloud capacity جدید اضافه شده را شروع کند.

Redundancy size

به منظور بازیابی فاجعه (disaster recovery)، ما  حداقل دو Horizon Pods را در دو لوکیشن جداگانه توصیه می‌کنیم. اگر چندین مکان را برای استفاده از یک Horizon Pod متمرکز با استفاده از این ویژگی ادغام می‌کنید، تأثیر آن را بر روی disaster recovery در نظر بگیرید و اطمینان حاصل کنید که  حداقل دو لوکیشن Horizon pods مستقل با مجموعه Connection Server های خودشان وجود دارد.

اگر هدف از رفتن به فضای Cloud پیاده‌سازی راه‌حل disaster recovery برای یک Horizon pod موجود باشد، باید تشخیص داد کهRemote agent  ها به تنهاییRedundancy  را میسر نمی‌کنند. برای این منظور، توصیه می‌کنیم که یک  Horizon podمستقل درcloud platform  مورد نظر راه‌اندازی کنید.

Pod Size

با استفاده از Remote capacity (other datacenters or cloud capacity) برای میزبانی virtual desktops و RDSH servers و پیاده‌سازی  Horizon agentبصورت Remote، محدودیت سایز و توصیه‌های single Horizon pod  را تغییر نمی‌دهد. هر Horizon Pod می‌تواند تا حداکثر 20000، session  را  میزبانی (Host) کند و گنجایش آن می‌تواند بیشتر از  (Capacity) 5 vCenter  را مورد استفاده قرار دهد.

Connection Servers

Horizon Connection Server ها در یک  single pod باید در یک location پیاده‌سازی شوند و نمی‌توان آنها را در میان private datacenters  و cloud datacenters  توسعه داد.

Unified Access Gateways

در صورت استفاده از Unified Access gateway، باید در همان مکانHorizon Connection Server  ها، پیاده‌سازی شوند. لوکیشن‌ها نقش مهمی دارند زیرا همهConnection Server ها از طریق لوکیشن انجام می‌شود و می‌تواند بر تأخیر، تاثیر بگذارد و  Unified Access Gatewaysدر هر Pod برای بیش از یک لوکیشن ساپورت نمی‌شود. اگر می‌خواهید Unified Access Gateway را در همان لوکیشن به عنوان remote agents انتخاب کنید، شما باید در مورد پیاده‌سازی استانداردhorizon pod  در آن لوکیشن با تمام زیرساخت های مدیریتی، ازجملهConnection server  ها بررسی و تحقیق نمایید.

قابلیت تأخیر (Latency)

تأخیر درData center  که در آنHorizon pod  موجود باConnection server  ها در آن پیاده‌سازی شده‌اند و هر موقعیت مکانی که در آنHorizon agent   پیاده‌سازی شده باید 120 میلی‌ثانیه یا کمتر باشد.

ارتباط شبکه‌ای بین Private Data center ها و cloud data center بسته به cloud provider متفاوت است. توصیة ما به شما این است که با VMware technical team و همچنین ارائه دهنده your cloud برای پیکربندی بهینه، کار کنید .

اتصال شبکه بین مراکز داده خصوصی و مراکز داده ابری بسته به ارائه دهنده ابر متفاوت است. توصیه می‌کنیم برای پیکربندی بهینه با تیم فنی VMware و همچنین ارائه دهنده ابر خود کار کنید.

شبکه سازی (Networking)

همانند هر پیاده‌سازی Horizon، شبکه‌سازی (Networking) و مسیریابی (Routing) صحیحی باید وجود داشته باشد تا برای برقراری ارتباط مناسب، اطمینان حاصل شود.

با پیاده‌سازیremote agent ، باید اطمینان حاصل شود  اجزایی که بصورتRemote  پیاده‌سازی شده‌اند می‌توانند به درستی با هم ارتباط برقرار کنند. نمودار بالا آیتم‌های کلیدی را با اعدادی که در دایره اشاره شده و جریان‌های ترافیکی مورد نیاز زیر، نشان می‌دهد.

• ارتباط serverها با vCenter Server  ها.
• Horizon agent در virtual Desktops یا RDSH Hosts به Connection Servers
• برای internal user sessions، Internal Horizon Clients به Horizon Agents
• برای external user sessions، Unified Access Gateways به Horizon Agents
• Horizon Agents به Active Directory Domain Controllers/file servers

Version

قابلیت استفاده از Remote agent در یکprivate data center  در هر نسخه پشتیبانی شده فعلی  Horizon 8و Horizon 7 اعمال می‌شود. پس از توسعه Horizon pod  برای مدیریت cloud capacity ، Horizon pod  فعلی باید Horizon 8 2006 یا جدیدتر را اجرا کند.اگر Horizon 2106 و نسخه‌های جدیدتر استفاده می‌شود، زمانی که شما Cloud vCenter را Add می‌نمایید، شما باید پیاده‌سازی صحیح را انتخاب کنید. اگر این گزینه به اشتباه انتخاب شده باشد، ممکن است instant clones به درستی  ایجاد نشود. اگر Horizon 2103 یا نسخة قبلی آن در حال استفاده است، می‌توانید نوع پیاده‌سازی vCenter ابری را در ADAM DB تنظیم کنید.

شناسایی محدودیت (know limitation)

در حال حاضر خدماتHorizon Control Plane service  همچنان قابلیت تمایز capacity در پیاده‌سازی چندین سایت را ندارد. در نتیجهImage Management Service  ، در هنگام استفاده برروی ویسنتری که به Connection server  ها به صورت ریموت وصل می‌شوند، کار نمی‌کند.

معماری چند سایت (Multi-site Architecture)

این معماری مرجع و تمامی ویژگی‌های Horizon را در دو Data center  مستند و تأیید می‌کند.

این معماری اصول اولیه زیر را دارد:

• Site redundancy: هر نقطه خرابی را که می‌تواند باعث قطعی سرویس شود را حذف کنید.
• Data replication: اطمینان حاصل کنید که هر لایه از Stack با Redundancy  بالا یا high availability  کانفیگ شده است. به طوری که خرابی یکComponent  بر در دسترس بودن کلی سرویس desktop، تأثیری نگذارد.

برای دستیابی به  Redundancy site

• خدمت‌هایی که با استفاده از Horizon در دو data center موجود است، قادر به فعالیت مستقل هستند.
• کاربران می‌توانند منابع معادل از مراکز داده اولیه و ثانویه را دریافت کنند.
• برخی از خدمات از هر دو data centers (active/active) در دسترس هستند.
• برخی از سرویس‌ها برای تبدیل secondary data center به سرویس زنده (active/passive)، به مراحل failover نیاز دارند.

برای دستیابی به Replication

• هر component ، application یا  data که برای ارائه سرویس در second data center مورد نیاز است در یک secondary site ، replication  می‌شود.
• اینService  می‌تواند با استفاده replicated components بازسازی شود.
• نوعreplication به نوع Components و data و Service ارائه شده بستگی دارد.
• حالت secondary copy (active or passive) به نوع Replication و نوع سرویس بستگی دارد.

مفهوم Active-Passive

معماریActive/passive  از دو یا چندPods  از Connection Servers  با حداقل یک Pod  که در هرData center   قرار دارد، استفاده می‌کند. Pod  ها با استفاده از معماری  cloud pod و کانفیگ شدن با (حقوق جهانی) global entitlements به یکدیگر متصل شده‌اند. مصرف Active – passive service باید از دیدگاه کاربر مشاهده گردد. یک کاربر به یکdata center  مشخص با (حقوق جهانی) global entitlements اختصاص داده می‌شود و وب‌سایت‌های کاربر پیکربندی می‌شوند. کاربر بطور فعال منابع Horizon را از آن Pod و سایت استفاده می‌کند و تنها در صورتی که سایت اصلی آنها در دسترس نباشد از سایت دیگر مصرف می‌کند.

مفهوم Active-Active

معماری Active-active همچنین از دو یا چند Pod  از Connection server  استفاده می‌کند که حداقل یک Pod  که در هرData center   قرار دارد. Pod  ها با استفاده از معماری  cloud pod که با (حقوق جهانی) global entitlements پیکربندی شده است، به هم متصل می‌شوند.همانند یک معماری Active\passive، مصرف سرویس Active\Active نیز باید از دیدگاه کاربر مشاهده شود. به یک کاربر (حقوق جهانی) global entitlements این اختیار داده می‌شود که منابع Horizon را از هر کدام ازPod   ها وsite ها بهره‌برداری کند و هیچ اولویتی به pod یا Site که آنها از آن مصرف می‌کنند داده نمی‌شود. چالش‌های موجود در این رویکرد معمولاً مربوط به تکرار داده‌های کاربر بین سایت‌ها مربوط هستند.

مفهوم Stretched Active-Active – Unsupported

این معماری پشتیبانی نمی‌شود و تنها در اینجا نشان‌داده شده‌ است تا تأکید کند که چرا پشتیبانی نمی‌شود. connection server ها درون یک سایت مشخص باید همیشه برروی یکLAN ، (well-connected) به خوبی متصل شوند و بنابراین نمی‌توانند همزمان در چندین مکان جغرافیایی به طور فعال اجرا شوند.

مفهوم Multi-site Global Server Load Balancing

یک رویکرد متداول وجود دارد که یک Single namespace  برای کاربران فراهم شود تا به Horizon pod های پیاده‌سازی شده در مکان های جداگانه دسترسی داشته باشند. یک راه‌حل Global Server Load balancer (GSLB) یا DNS load balancer این قابلیت را ارائه می‌دهد و می‌تواند از منطق جای‌گذاری برای هدایت ترافیک به local load balancer  در یک سایت محلی استفاده کند. برخی از GSLB ها می‌توانند از اطلاعاتی مانند user ” s location برای تعیین محل اتصال استفاده کنند. استفاده از یکSingle name space   برای کاربران ساده‌تر است و امکان اعمال تغییرات اجرایی یا پیاده‌سازی disaster recovery و  failover بدون نیاز به کاربران برای تغییر شیوه دسترسی آن‌ها به محیط را فراهم می‌کند.

به ویژگی‌های زیر در مورد GLSB دقت کنید:

• GLSB شبیه به سرویس Domain Name System  (DNS) است که یک نام را Resolve  می‌کند و برای یک IP  Address ترافیک را هدایت می‌کند.
• درمقایسه با سرویس DNS، GSLB  معمولاً در هنگام resolve پرس‌وجوی نام( resolving a name query)، معیارهای اضافی اعمال می‌کند.
• ترافیک در واقع از طریق GSLB به end server جریان ندارد.
• همانند سرور DNS ، GLSB  (Similar to a DNS server, the GLSB does not provide any port information in its resolution.) GLSB باید در چندین Node  در پیکربندی HA، Active/passive پیاده‌سازی شوند و اطمینان حاصل کند که خود GLSB  به یک نقطه شکست تبدیل نمی‌شود.

مفهوم Multi-site Architecture Diagram

نمودار زیر server component و معماری منطقی برای پیاده‌سازی چند سایت Horizon را نشان می‌دهد. برای وضوح، تمرکز در این نمودار به جهت نشان‌دادن اجزای اصلی سرور Horizon است، بنابراین شامل component  های اضافی و اختیاری مانند App Volumes ، Dynamic Environment Manager  و workspace one Access نیست.

نمودار زیر server component و معماری منطقی برای پیاده‌سازی چند Pod Horizon از جمله component های اضافی را نشان می‌دهد، همچنین می‌تواند برای pods که در موقعیت‌های مختلف یا متفاوت پیاده‌سازی می‌شوند، اعمال شود.

Universal Broker برای ارائه یک FQDN ( Fully Qualified Domain Name) برای اتصال کاربران و سپس دسترسی به وظایف در هر Horizon pod  استفاده می‌شود. هر سایت دارای یک نمونه جداگانه از App volume ها با مجموعه App Volumes Managers خودش است و مجموعه‌ای از اشتراک‌گذاری فایل برای Dynamic Environment Manager است. Share که توسط IT  کانفیک شده را می‌توان در هر دو سایت replicate و در دسترس قرار داد، زیرا کاربران تنها به دسترسی خواندن نیاز دارند. اشتراک گذاری Profile Archive تنها برای کاربران در سایت فعال هستند. اگرچه آنها می‌توانند در یک مکان دیگریreplicate  شوند خصوصاً در زمان قطعی برق.

معرفی Composer Server

یک Composer server تنها زمانی موردنیاز است که از linked clone  استفاده می‌کند و روش قدیمی برای ایجاد Clone  ها می‌باشد. در Horizon 8 2006 منسوخ شد و از Horizon 8 2012 به بعد دیگر پشتیبانی نمی شود. Instant clones به composer server  نیاز ندارند و توصیة ما این است که از  instant clone  به‌جای linked clones را در اولویت با linked clone استفاده کنیم.

برای این که در این مورد migrating from legacy components  مانند View Composer، persistent disks، و Management to modern alternatives می باشد، Option  ها و راهنمایی‌ها  Modernizing VDI for a New Horizon  را ببینید.

سرویس Composer  با Connection Server ها و vCenter  کار می‌کند. هر Composer server  با یک vCenter Server  در یک ارتباط یک به یکPair  می‌شود. به عنوان مثال، در block architecture  که در آن ما یک  vCenter server به ازای هر 4000 VM کلون link شده داریم، یک سرور Composer نیز خواهیم داشت.

قابلیتhigh availability   توسط HA  ارائه شده است، که  Composer VM را در صورت قطع برق vSphere host  مجدداً راه‌اندازی می‌کند. VM monitoring با vSphere HA همچنین می‌تواند برای راه‌اندازی مجدد VM در صورت خرابی سیستم عامل تلاش کند.

اگر سرویسVMware View Composer  در دسترس نباشد، تمامی Desktop های موجود می‌توانند به کار خود ادامه دهند. درحالی‌کهvSphere HA   در حال راه‌اندازی مجدد Composer VM است، تنها تأثیر آن بر روی provisioning tasks در داخل بلاک است. مانند image refreshes یا recomposes یا ایجاد new linked clone pools.