بهترین شیوه های AWS، بهترین شیوه های AWS

این بخش بهترین شیوه های ما را خلاصه می کند و توصیه های ما را برای استفاده از OPDK با ابر AWS ارائه می دهد.

Cassandra به عنوان یک Backend و Datastore برای تقریباً همه سیاست ها استفاده می شود و بخش مهمی از محیط اجرای Apigee Edge است. این سند بر بهینه سازی Casssandra برای محیط AWS تمرکز دارد.

نیازهای ذخیره سازی و I/O

بیشتر ورودی/خروجی کاساندرا متوالی است، اما مواردی وجود دارد که به ورودی/خروجی تصادفی نیاز دارید. یک مثال هنگام خواندن جداول رشته مرتب شده در طول عملیات خواندن است. SSD مکانیسم ذخیره‌سازی توصیه شده برای Cassandra است، زیرا زمان‌های پاسخ بسیار کم را برای عملیات خواندن تصادفی فراهم می‌کند در حالی که عملکرد نوشتن متوالی کافی را برای عملیات فشرده‌سازی فراهم می‌کند. تکرار نیز در اینجا در نظر گرفته شده است.

بسیاری از نمونه‌ها در AWS EC2 دارای حافظه محلی هستند که در آن هارد دیسک به طور فیزیکی به سخت‌افزاری که نمونه EC2 روی آن میزبانی می‌شود متصل است. Apigee توصیه می‌کند هنگام اجرای Cassandra در تولید، از SSD و instance stores استفاده کنید. هنگامی که از یک نوع نمونه با بیش از 1 SSD استفاده می کنید، می توانید از RAID0 برای دستیابی به توان عملیاتی و ظرفیت ذخیره سازی بیشتر استفاده کنید.

الزامات شبکه

Cassandra از پروتکل Gossip برای تبادل اطلاعات با گره های دیگر در مورد توپولوژی شبکه استفاده می کند. استفاده از Gossip به علاوه ماهیت توزیع شده Cassandra - که شامل مکالمه با چندین گره برای عملیات خواندن و نوشتن است - منجر به انتقال داده های زیادی از طریق شبکه می شود. Apigee استفاده از نوع Instance با حداقل پهنای باند شبکه 1Gbps و بیش از 1Gbps را برای سیستم های تولیدی توصیه می کند.

از VPC با CIDR 16/ استفاده کنید. از آنجایی که زیرشبکه ها در AWS نمی توانند بیش از 1 AZ را پوشش دهند، Apigee موارد زیر را توصیه می کند:

• ایجاد 1 زیرشبکه در هر منطقه در دسترس (AZ)
• از 3 زیرشبکه خصوصی برای نصب Apigee خود با یک گره Cassandra در هر AZ استفاده کنید. 3 زیرشبکه باید بلوک‌های CIDR کافی برای تطبیق با گسترش افقی خوشه کاساندرا داشته باشند.
• 3 زیرشبکه عمومی را با NAT اختصاصی برای Cassandra پیکربندی کنید تا بتوانید برای دانلود نرم افزار و به روز رسانی های امنیتی با اینترنت صحبت کنید.

برخلاف معماری‌های ارث برده، کاساندرا دارای معماری بدون استاد است که در آن همه گره‌ها نقش یکسانی را ایفا می‌کنند، بنابراین هیچ نقطه‌ای از شکست وجود ندارد. برای فعال کردن دسترسی بالا، گره‌های کاساندرا را در چندین AZ پخش کنید. با گسترش گره ها در AZ، همچنان می توانید در صورت بروز فاجعه، در دسترس بودن و زمان کار را حفظ کنید.

انتخاب خانواده نمونه

وقتی به نیازهای CPU Cassandra نگاه می کنیم، توجه به این نکته مفید است که بارهای کاری سنگین در Cassandra قبل از تبدیل شدن به IO-bound به CPU محدود می شوند. به عبارت دیگر، تمام عملیات نوشتن به گزارش commit می رود، اما Cassandra در نوشتن آنقدر کارآمد است که CPU به عامل محدود کننده تبدیل می شود. Cassandra به شدت همزمان است و از تعداد هسته های CPU در دسترس استفاده می کند.

Apigee استفاده از یک خانواده نمونه را توصیه می کند که تعادلی بین CPU و حافظه دارد. به طور خاص، توصیه می کنیم از نمونه های خانواده C5 در صورت موجود بودن در منطقه AWS و C3 به عنوان گزینه بازگشتی استفاده کنید. در برخی موارد، 4xlarge نمونه بهینه در هر دو خانواده است که بهترین قیمت/عملکرد را ارائه می‌کند.

Apigee همچنین استفاده از اجاره پیش فرض را برای نمونه های Cassandra توصیه می کند. وقتی به بیش از 1 نمونه در هر AZ مقیاس می‌دهید، به احتمال زیاد تمام نمونه‌های Cassandra شما بر روی همان سخت‌افزار زیربنایی قرار می‌گیرند، اگر قرارداد اجاره را اختصاص داده باشید. بنابراین، هنگامی که سخت افزار خراب می شود، احتمالاً تمام نمونه های خود را در آن AZ از دست خواهید داد.

خلاصه توصیه

جدول زیر توصیه های Apigee را برای استفاده از AWS با Apigee Edge برای Private Cloud خلاصه می کند:

برای اطلاعات بیشتر، انواع نمونه های آمازون را ببینید.