پرش به مطلب اصلی

تنظیمات پیشرفته

با استفاده از «تنظیمات پیشرفته» در CDN ابر آروان، می‌توانید ترافیک کاربران‌ و رفتار توزیع‌ بار را به‌شکل دقیق‌تری مدیریت کنید. پس از انتخاب دامنه و ورود به پیشخان آن در پنل CDN ابر آروان از بخش «ترافیک» و سپس «تنظیمات پیشرفته» می‌توانید به این امکانات دسترسی داشته باشید.

نوع توزیع بار

در این بخش می‌توانید الگوریتمی‌ را که بر اساس آن یک آدرس از میان آدرس سرورهای اصلی انتخاب می‌شود، مشخص کنید.

  • الگوریتم Round Robin

    این الگوریتم ساده‌ترین و رایج‌ترین الگوریتم توزیع بار است. درخواست‌های کاربران در چرخشی ساده بین سرورهای اصلی شما توزیع می‌شوند. برای نمونه، تصور کنید ۶ کاربر (u5، u4، u3، u2، u1 و u6) دارید که می‌خواهند به اپلیکیشن شما متصل شوند و شما ۳ سرور (s2، s1 و s3) دارید. u1 به u2 ،s1 به s2 و u3 به s3 و در ادامه u4 به u5 ،s1 به s2 و u6 به s3 متصل می‌شود. الگوریتم Round Robin برای درخواست‌های قابل پیش‌بینی و سرورهایی با توان پردازشی و منابع نسبتن مساوی، مناسب هستند.

    اما اگر یکی از سرورها نسبت به بقیه ظرفیت بیش‌تری برای رسیدگی به درخواست‌ها داشته باشد، می‌توان به کمک وزن‌دهی از نهایت قدرت آن سرور استفاده کرد.

  • الگوریتم Client IP Hash

    Client IP Hash الگوریتمی‌ است که درخواست‌های کاربران را بر اساس آدرس IP آن‌ها به یک سرور مشخص ارسال می‌کند.

    هنگامی‌ که کاربر درخواستی را ارسال می‌کند، ابتدا Load Balancer آن را دریافت می‌کند. سپس Load Balancer از آدرس IP کاربر در یک تابع Hash استفاده می‌کند. ویژگی‌های این تابع Hash می‌تواند متفاوت باشد. برای نمونه، ممکن است آخرین اکتت آدرس IP را به یک عدد صحیح تبدیل کند و یک عملیات مد روی تعداد سرورها انجام دهد تا شاخص سرور را دریافت کند. در واقع، تابع هش تعیین می‌کند که کدام سرور باید درخواست را بر اساس Hash آدرس IP کاربر پردازش کند.

    تا زمانی که تعداد سرورها ثابت بماند و IP تغییر نکند، تمام درخواست‌های آینده از آن آدرس IP به همان سرور هدایت می‌شوند.

    این الگوریتم تداوم یک Session را تضمین می‌کند. به این معنا که تا زمانی که آدرس IP یک کاربر تغییر نکند، در طول Session خود به‌طور مداوم به همان سرور متصل می‌شود. این ویژگی در شرایطی که حفظ اطلاعات Session در مورد کلاینت و در یک سرور خاص مهم است کارایی دارد.

ارسال درخواست کاربر به سرور بعدی هنگام بروز خطا

با فعال‌سازی این قابلیت، اگر زیردامنه‌ی شما به بیش از یک سرور متصل باشد، درخواست‌هایی که با خطای Connection Refused ،Connection Error و ... روبه‌رو شوند به‌شکل خودکار به سرور بعدی منتقل می‌شوند و در این حالت خطای سرور اصلی به کاربر نمایش داده نمی‌شود.

با کلیک روی تنظیمات می‌توانید مشخص کنید با بروز چه خطا (Status Code) و متدی (HTTP Method) درخواست کاربر به سرور بعدی در لیست سرورهای Upstream ارسال شود.

توجه داشته باشید درخواست‌هایی که از Upstream با خطا رو‌به‌رو شوند، ممکن است در فرآیند درخواست در سرور دوم با مشکل مواجه شوند. برای نمونه، اگر هنگام اجرای یک Query به‌دلیل مشکلات شبکه، اتصال قطع و ترافیک به سرور بعدی ارسال شود ممکن است رکوردهای تکراری در دیتابیس ایجاد شود.

این قابلیت در پلن‌های رشد و بالاتر در دسترس قرار دارد.

توقف ارسال ترافیک به سرور خطادار

با فعال کردن این امکان، به‌شکل پیش‌فرض اگر تعداد خطاهای یک سرور از ۵ بیش‌تر شود، آن سرور به‌مدت ۱۵ ثانیه از لیست سرورهایی که ترافیک برای آن‌ها ارسال می‌شود، خارج می‌شود.

تعداد خطا و مدت زمانی که ترافیک برای سرور دارای خطا ارسال نمی‌شود، در بخش تنظیمات قابل تغییر است.

این قابلیت در پلن‌های رشد و بالاتر در دسترس قرار دارند.

پایداری ارتباط با سرور اصلی

با فعال کردن این ویژگی، Connectionهای برقرار شده با سرور اصلی برای استفاده در درخواست‌های متوالی باز نگه‌ داشته می‌شوند. در نتیجه، تعداد کانکشن های ایجاد‌شده با سرور اصلی کاهش می‌یابد.

در HTTP/1.0، برای هر جفت Request-Response، یک اتصال جدید برقرار و قطع می‌شود. این فرآیند باری که به سرورها وارد می‌شود را به شدت بالا می‌برد.

اما در HTTP/1.1، ویژگی Keep Alive Connection به حالت پیش‌فرض تبدیل شده است؛ یعنی پس از این‌که کلاینت با سرور ارتباط برقرار کرد، از همان اتصال برای درخواست‌های بعدی استفاده می‌شود. این کار هزینه‌ی ایجاد یک اتصال جدید برای هر جفت Request-Response را کاهش می‌دهد.

به‌طور کلی، Keep Alive Connection با کاهش تاخیر ارتباط و صرفه‌جویی در مصرف CPU، عملکرد وب‌سایت‌ها را تا حد زیادی بهبود می‌بخشد.

gRPC

gRPC یک پروتکل ارتباطی باز و پرسرعت است که گوگل آن را توسعه داده است. این پروتکل مبتنی‌بر HTTP/2 است و از پروتکل‌های باینری برای انتقال داده‌ها استفاده می‌کند، که آن را سریع‌تر و کارآمدتر از HTTP/1 می‌کند. gRPC به‌ویژه برای ارتباط بین میکروسرویس‌ها و برنامه‌های توزیع‌شده طراحی شده است و امکان انجام درخواست‌های هم‌زمان، فشرده‌سازی داده‌ها، و استفاده از استریم‌های دوطرفه را فراهم می‌کند.

با فعال کردن gRPC شما می‌توانید درخواست‌ها و پاسخ‌های gRPC خود را از طریق شبکه توزیع شده CDN ارسال کنید، که باعث کاهش تاخیر و افزایش سرعت انتقال داده‌ها می‌شود. این ویژگی به‌ویژه برای اپلیکیشن‌های بلادرنگ (Real Time)، مانند چت‌ها یا خدمات ویدیویی، که به تاخیر کم نیاز دارند، مفید است.

شرط استفاده از gRPC

در حالت ترافیک gRPC، امکان انتخاب Host Header متفاوت برای هر Origin در استخر ها وجود ندارد. سیستم به‌شکل پیش‌فرض Host Header مربوط به اولین Origin تعریف‌شده را انتخاب کرده و همان را برای تمام Originها استفاده می‌کند.

بنابراین اگر سرویس شما نیازمند هاست‌هدرهای متمایز برای هر Origin باشد، این قابلیت در gRPC پشتیبانی نخواهد شد.

پورت و پروتکل‌های پشتیبانی‌شده

ارایه‌ی سرویس gRPC تنها از طریق پورت‌های TLS (مانند 443) امکان‌پذیر است. gRPC فقط بر بستر HTTP/2 پشتیبانی می‌شود و روی HTTP/1.1 یا پورت‌های غیر TLS در دسترس نیست. اگر تلاشی برای استفاده از پورت‌های غیرامن یا پروتکل نامعتبر انجام شود، اتصال به‌وسیله‌ی CDN برقرار نخواهد شد.

تشخیص ترافیک gRPC

سرویس CDN فقط بر اساس هدر Content-Type: application/grpc می‌تواند ترافیک gRPC را شناسایی کند.

اگر کلاینت شما از gRPC استفاده کند اما مقدار هدر Content-Type متفاوت از application/grpc باشد، ترافیک شما gRPC شناسایی نخواهد شد و ممکن است به‌شکل ترافیک HTTP پردازش شود.

توصیه می‌شود کلاینت‌ها به‌طور شفاف این هدر را در تمام درخواست‌های gRPC خود ارسال کنند.

فعال‌سازی با API

برای پیکربندی و مدیریت تنظیمات پیشرفته‌ی توزیع بار CDN آروان از طریق API می‌توانید از نمونه درخواست زیر استفاده کنید:

curl --location --request PATCH 'https://napi.arvancloud.ir/cdn/4.0/domains/arian.run/load-balancers/settings' \
--header 'authority: napi.arvancloud.ir' \
--header 'accept: application/json, text/plain, */*' \
--header 'authorization: API KEY' \
--header 'Content-Type: text/plain' \
--data '{"method":"cluster_chash","next_upstream_tcp":"on","protocol":"https","keepalive":"on","max_fails":5,"fail_timeout":"10s"}'
  • در این درخواست کلید method برای مدیریت نوع توزیع بار استفاده می‌شود و برای الگوریتم Round Robin مقدار cluster-rr و برای الگوریتم Client IP Hash مقدار cluster-chash را می‌پذیرد.

  • برای مدیریت ویژگی «ارسال درخواست کاربر به سرور بعدی هنگام بروز خطا» کلید next_upstream_tcp می‌تواند دو مقدار on و off را دریافت می‌کند.

  • مدیریت تنظیمات «توقف ارسال ترافیک به سرور خطادار» با استفاده از دو کلید max_fails و fail_timeout انجام می‌شود که به ترتیب یک عدد صحیح مثبت و یک مقدار زمانی بر حسب ثانیه را می‌پذیرد.

  • برای «پایداری ارتباط با سرور اصلی» باید از کلید keepalive استفاده کنید. این پارامتر می‌تواند دو مقدار on و off را دریافت کند.