VMware NSX برای کوچولوها. قسمت 5: پیکربندی یک بار متعادل کننده

بخش اول. مقدماتی
بخش دوم. پیکربندی فایروال و قوانین NAT
قسمت سوم. پیکربندی DHCP
قسمت چهارم راه اندازی مسیریابی

آخرین بار در مورد قابلیت های NSX Edge در مسیریابی استاتیک و پویا صحبت کردیم و امروز به load balancer می پردازیم.
قبل از شروع راه اندازی، می خواهم به طور خلاصه انواع اصلی تعادل را یادآوری کنم.

Теория

همه راه حل های متعادل کننده بار امروزی اغلب به دو دسته تقسیم می شوند: تعادل در سطح چهارم (حمل و نقل) و هفتم (کاربرد) مدل. یا اگر. مدل OSI بهترین نقطه مرجع در هنگام توصیف روش های متعادل سازی نیست. به عنوان مثال، اگر یک بالانس L4 از ترمینال TLS نیز پشتیبانی کند، آیا به تعادل L7 تبدیل می شود؟ اما این همینه که هست.

• بالانس L4 اغلب یک پروکسی میانی است که بین مشتری و مجموعه‌ای از باطن‌های موجود ایستاده است، که اتصالات TCP را خاتمه می‌دهد (یعنی به طور مستقل به SYN پاسخ می‌دهد)، یک باطن را انتخاب می‌کند و یک جلسه TCP جدید را در جهت خود آغاز می‌کند و به طور مستقل SYN را ارسال می‌کند. این نوع یکی از موارد اساسی است؛ گزینه های دیگری امکان پذیر است.
• بالانس L7 ترافیک را در میان باطن های موجود "پیچیده تر" از متعادل کننده L4 توزیع می کند. می‌تواند بر اساس محتوای پیام HTTP (URL، کوکی و غیره) تصمیم بگیرد که کدام backend را انتخاب کند.

صرف نظر از نوع، متعادل کننده می تواند عملکردهای زیر را پشتیبانی کند:

• کشف سرویس فرآیند تعیین مجموعه پشتیبان های موجود (Static، DNS، Consul، Etcd و غیره) است.
• بررسی عملکرد پشتیبان های شناسایی شده (پینگ فعال باطن با استفاده از درخواست HTTP، تشخیص غیرفعال مشکلات در اتصالات TCP، وجود چندین کد 503 HTTP در پاسخ ها و غیره).
• خود موازنه (گردی، انتخاب تصادفی، هش IP منبع، URI).
• خاتمه TLS و تأیید گواهی.
• گزینه های مرتبط با امنیت (احراز هویت، جلوگیری از حمله DoS، محدود کردن سرعت) و موارد دیگر.

NSX Edge از دو حالت استقرار متعادل کننده بار پشتیبانی می کند:

حالت پروکسی یا یک بازویی. در این حالت، NSX Edge از آدرس IP خود به عنوان آدرس منبع هنگام ارسال درخواست به یکی از backendها استفاده می کند. بنابراین، متعادل کننده به طور همزمان وظایف منبع و مقصد NAT را انجام می دهد. Backend تمام ترافیک را به عنوان ارسال شده از متعادل کننده می بیند و مستقیماً به آن پاسخ می دهد. در چنین طرحی، متعادل کننده باید در همان بخش شبکه با سرورهای داخلی باشد.

در اینجا چگونه پیش می رود:
1. کاربر درخواستی را به آدرس VIP (آدرس متعادل کننده) که در Edge پیکربندی شده است ارسال می کند.
2. Edge یکی از backendها را انتخاب می کند و NAT مقصد را انجام می دهد و آدرس VIP را با آدرس backend انتخاب شده جایگزین می کند.
3. Edge NAT منبع را انجام می دهد و آدرس کاربری که درخواست را ارسال کرده با آدرس خود جایگزین می کند.
4. بسته به باطن انتخاب شده ارسال می شود.
5. باطن مستقیماً به کاربر پاسخ نمی دهد، بلکه به Edge پاسخ می دهد، زیرا آدرس اصلی کاربر به آدرس متعادل کننده تغییر یافته است.
6. Edge پاسخ سرور را به کاربر منتقل می کند.
نمودار زیر است.


حالت شفاف یا درون خطی. در این سناریو، متعادل کننده دارای رابط هایی در شبکه های داخلی و خارجی است. در عین حال، هیچ دسترسی مستقیمی به شبکه داخلی از شبکه خارجی وجود ندارد. متعادل کننده بار داخلی به عنوان یک دروازه NAT برای ماشین های مجازی در شبکه داخلی عمل می کند.

مکانیسم به شرح زیر است:
1. کاربر درخواستی را به آدرس VIP (آدرس متعادل کننده) که در Edge پیکربندی شده است ارسال می کند.
2. Edge یکی از backendها را انتخاب می کند و NAT مقصد را انجام می دهد و آدرس VIP را با آدرس backend انتخاب شده جایگزین می کند.
3. بسته به باطن انتخاب شده ارسال می شود.
4. Backend درخواستی با آدرس اصلی کاربر دریافت می کند (منبع NAT انجام نشده است) و مستقیماً به آن پاسخ می دهد.
5. ترافیک دوباره توسط بار متعادل کننده پذیرفته می شود، زیرا در یک طرح درون خطی معمولاً به عنوان دروازه پیش فرض برای مزرعه سرور عمل می کند.
6. Edge با استفاده از VIP خود به عنوان آدرس IP منبع، NAT منبع را برای ارسال ترافیک به کاربر انجام می دهد.
نمودار زیر است.

عمل

میز تست من دارای 3 سرور در حال اجرا Apache است که برای کار بر روی HTTPS پیکربندی شده است. Edge متعادل کردن درخواست‌های HTTPS را انجام می‌دهد و هر درخواست جدید را به یک سرور جدید پراکسی می‌کند.
بیایید شروع کنیم.

تولید یک گواهی SSL که توسط NSX Edge استفاده خواهد شد
می‌توانید یک گواهی CA معتبر وارد کنید یا از یک گواهی خودامضا استفاده کنید. برای این آزمون من از خود امضا استفاده خواهم کرد.

1. در رابط vCloud Director، به تنظیمات Edge services بروید.
   
2. به تب Certificates بروید. از لیست اقدامات، افزودن یک CSR جدید را انتخاب کنید.
   
3. فیلدهای مورد نیاز را پر کنید و روی Keep کلیک کنید.
   
4. CSR جدید ایجاد شده را انتخاب کنید و گزینه self-sign CSR را انتخاب کنید.
   
5. مدت اعتبار گواهی را انتخاب کرده و روی Keep کلیک کنید
   
6. گواهی خود امضا شده در لیست گواهی های موجود ظاهر می شود.
   

تنظیم نمایه برنامه
پروفایل های برنامه به شما کنترل کامل تری بر ترافیک شبکه می دهد و مدیریت آن را ساده و موثر می کند. آنها می توانند برای تعریف رفتار برای انواع خاصی از ترافیک استفاده شوند.

1. به تب Load Balancer بروید و متعادل کننده را فعال کنید. گزینه Acceleration enabled در اینجا به متعادل کننده اجازه می دهد تا به جای L4 از تعادل L7 سریعتر استفاده کند.
   
2. برای تنظیم نمایه برنامه، به تب نمایه برنامه بروید. روی + کلیک کنید.
   
3. نام نمایه را تنظیم کرده و نوع ترافیکی که نمایه برای آن اعمال می شود را انتخاب کنید. اجازه دهید چند پارامتر را توضیح دهم.
   اصرار - داده های جلسه را ذخیره و ردیابی می کند، به عنوان مثال: کدام سرور خاص در استخر به درخواست کاربر سرویس می دهد. این تضمین می‌کند که درخواست‌های کاربر برای تمام طول جلسه یا جلسات بعدی به همان عضو pool هدایت می‌شوند.
   عبور SSL را فعال کنید – با انتخاب این گزینه، NSX Edge پایان دادن به SSL را متوقف می کند. در عوض، خاتمه به طور مستقیم در سرورهایی که در حال بالانس هستند رخ می دهد.
   هدر X-Forwarded-For HTTP را درج کنید - به شما امکان می دهد آدرس IP منبع مشتری متصل به وب سرور را از طریق متعادل کننده بار تعیین کنید.
   Pool Side SSL را فعال کنید – به شما امکان می دهد مشخص کنید که استخر انتخاب شده از سرورهای HTTPS تشکیل شده باشد.
   
4. از آنجایی که ترافیک HTTPS را متعادل می کنم، باید Pool Side SSL را فعال کنم و گواهی ایجاد شده قبلی را در برگه Certificates Server -> Service Certificate انتخاب کنم.
   
5. به طور مشابه برای گواهی استخر -> گواهی خدمات.
   

ما مجموعه ای از سرورها را ایجاد می کنیم که ترافیک آن ها Pools متعادل خواهد بود

1. به تب Pools بروید. روی + کلیک کنید.
   
2. نام استخر را تنظیم می کنیم، الگوریتم (من از دور روبین استفاده خواهم کرد) و نوع نظارت را برای باطن چک سلامت انتخاب می کنیم، گزینه Transparent نشان می دهد که آیا IP های منبع اولیه کلاینت ها برای سرورهای داخلی قابل مشاهده است یا خیر.
   • اگر این گزینه غیرفعال باشد، ترافیک سرورهای داخلی از IP منبع متعادل کننده می آید.
   • اگر این گزینه فعال باشد، سرورهای داخلی IP منبع کلاینت ها را می بینند. در این پیکربندی، NSX Edge باید به عنوان دروازه پیش فرض عمل کند تا اطمینان حاصل شود که بسته های برگشتی از NSX Edge عبور می کنند.

   NSX از الگوریتم های متعادل کننده زیر پشتیبانی می کند:

   • IP_HASH – انتخاب سرور بر اساس نتایج یک تابع هش برای IP مبدا و مقصد هر بسته.
   • LEASTCONN - متعادل کردن اتصالات ورودی، بسته به تعداد موجود در یک سرور خاص. اتصالات جدید به سروری با کمترین اتصال هدایت می شود.
   • درخواست کتبی - اتصالات جدید به نوبه خود به هر سرور مطابق با وزن اختصاص داده شده به آن ارسال می شود.
   • URI – قسمت سمت چپ URI (قبل از علامت سوال) هش شده و بر وزن کل سرورها در استخر تقسیم می شود. نتیجه نشان می‌دهد که کدام سرور درخواست را دریافت می‌کند و اطمینان می‌دهد که درخواست همیشه به همان سرور هدایت می‌شود، تا زمانی که همه سرورها در دسترس باشند.
   • HTTPHEADER - تعادل بر اساس یک هدر HTTP خاص، که می تواند به عنوان یک پارامتر مشخص شود. اگر هدر وجود نداشته باشد یا مقداری نداشته باشد، الگوریتم ROUND_ROBIN اعمال می شود.
   • URL – هر درخواست HTTP GET پارامتر URL مشخص شده به عنوان آرگومان را جستجو می کند. اگر پارامتر با علامت مساوی و یک مقدار دنبال شود، آنگاه مقدار هش شده و بر وزن کل سرورهای در حال اجرا تقسیم می شود. نتیجه نشان می دهد که کدام سرور درخواست را دریافت می کند. این فرآیند برای پیگیری شناسه‌های کاربر در درخواست‌ها و اطمینان از اینکه شناسه کاربری یکسان همیشه به همان سرور ارسال می‌شود، تا زمانی که همه سرورها در دسترس هستند، استفاده می‌شود.

   

3. در بلوک اعضا، روی + کلیک کنید تا سرورها را به استخر اضافه کنید.
   
   
   در اینجا باید نشان دهید:
   • نام ارائهکننده؛
   • آدرس آی پی سرور؛
   • پورتی که سرور در آن ترافیک دریافت می کند.
   • پورت برای بررسی سلامت (مانیتور سلامت چک)؛
   • وزن - با استفاده از این پارامتر می توانید مقدار متناسب ترافیک دریافتی را برای یک عضو خاص استخر تنظیم کنید.
   • حداکثر اتصال - حداکثر تعداد اتصالات به سرور.
   • حداقل اتصالات - حداقل تعداد اتصالاتی که سرور باید قبل از ارسال ترافیک به عضو بعدی استخر پردازش کند.

   
   
   این چیزی است که مجموعه نهایی سه سرور به نظر می رسد.
   

افزودن سرور مجازی

1. به تب سرورهای مجازی بروید. روی + کلیک کنید.
   
2. سرور مجازی را با استفاده از Enable Virtual Server فعال می کنیم.
   ما به آن یک نام می‌دهیم، نمایه برنامه ایجاد شده قبلی، Pool را انتخاب می‌کنیم و آدرس IP را که سرور مجازی درخواست‌هایی را از خارج دریافت می‌کند، نشان می‌دهیم. پروتکل HTTPS و پورت 443 را مشخص می کنیم.
   پارامترهای اختیاری در اینجا:
   محدودیت اتصال - حداکثر تعداد اتصالات همزمان که سرور مجازی می تواند پردازش کند.
   محدودیت نرخ اتصال (CPS) - حداکثر تعداد درخواست های دریافتی جدید در هر ثانیه.
   

این کار پیکربندی متعادل کننده را کامل می کند؛ می توانید عملکرد آن را بررسی کنید. سرورها یک پیکربندی ساده دارند که به شما امکان می دهد بفهمید کدام سرور از استخر درخواست را پردازش کرده است. در حین راه اندازی، الگوریتم تعادل Round Robin را انتخاب کردیم و پارامتر Weight برای هر سرور برابر با یک است، بنابراین هر درخواست بعدی توسط سرور بعدی از استخر پردازش می شود.
آدرس خارجی متعادل کننده را در مرورگر وارد می کنیم و می بینیم:


پس از رفرش صفحه، درخواست توسط سرور زیر پردازش می شود:


و دوباره - برای بررسی سرور سوم از استخر:


هنگام بررسی، می بینید که گواهینامه ای که Edge برای ما ارسال می کند، همان گواهی است که در همان ابتدا تولید کردیم.

بررسی وضعیت متعادل کننده از کنسول Edge Gateway. برای این کار وارد شوید نمایش استخر لودبالانسر خدمات.


پیکربندی مانیتور سرویس برای بررسی وضعیت سرورها در استخر
با استفاده از Service Monitor می‌توانیم وضعیت سرورها را در backend pool نظارت کنیم. اگر پاسخ به یک درخواست مطابق انتظار نباشد، می توان سرور را از استخر خارج کرد تا درخواست جدیدی دریافت نکند.
به طور پیش فرض، سه روش تأیید پیکربندی شده است:

• مانیتور TCP
• مانیتور HTTP،
• مانیتور HTTPS.

بیایید یک مورد جدید ایجاد کنیم.

1. به تب Service Monitoring بروید، روی + کلیک کنید.
   
2. انتخاب کنید:
   • نام روش جدید؛
   • فاصله زمانی که درخواست ها ارسال می شود،
   • زمان انتظار برای پاسخ،
   • نوع نظارت - درخواست HTTPS با استفاده از روش GET، کد وضعیت مورد انتظار - 200 (OK) و URL درخواست.
3. این کار راه اندازی سرویس مانیتور جدید را تکمیل می کند؛ اکنون می توانیم هنگام ایجاد یک استخر از آن استفاده کنیم.
   

تنظیم قوانین برنامه

Application Rules راهی برای دستکاری ترافیک بر اساس محرک های خاص است. با این ابزار می‌توانیم قوانین متعادل‌سازی بار پیشرفته‌ای ایجاد کنیم که ممکن است از طریق پروفایل‌های برنامه یا سایر خدمات موجود در Edge Gateway امکان‌پذیر نباشد.

1. برای ایجاد یک قانون، به زبانه Application Rules تعادل‌دهنده بروید.
   
2. یک نام، یک اسکریپت که از قانون استفاده می کند انتخاب کنید و روی Keep کلیک کنید.
   
3. پس از ایجاد قانون، باید سرور مجازی پیکربندی شده قبلی را ویرایش کنیم.
   
4. در تب Advanced، قانون ایجاد شده را اضافه کنید.
   

در مثال بالا پشتیبانی tlsv1 را فعال کردیم.

چند مثال دیگر:

ترافیک را به استخر دیگری هدایت کنید.
با این اسکریپت می‌توانیم ترافیک را به یک استخر تعادلی دیگر هدایت کنیم، اگر استخر اصلی خراب باشد. برای اینکه این قانون کار کند، باید چندین Pool روی متعادل کننده پیکربندی شود و همه اعضای استخر اصلی باید در حالت پایین باشند. شما باید نام استخر را مشخص کنید نه شناسه آن.

acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME


ترافیک را به یک منبع خارجی هدایت کنید.
در اینجا اگر همه اعضای استخر اصلی خراب باشند، ترافیک را به وب سایت خارجی هدایت می کنیم.

acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down

حتی نمونه های بیشتر اینجا.

این همه چیز برای من در مورد متعادل کننده است. اگر سوالی دارید بپرسید، من آماده پاسخگویی هستم.

منبع: www.habr.com