این بخش روال‌های مطلوب ما را خلاصه می‌کند و توصیه‌های ما را برای استفاده از OPDK با ابر AWS ارائه می‌دهد.
Cassandra به‌عنوان زیرینه و مخزن داده برای تقریباً همه خط‌مشی‌ها استفاده می‌شود و بخش مهمی از محیط زمان اجرای Apigee Edge است. این سند بر بهینه‌سازی Cassandra برای محیط AWS تمرکز دارد.
الزامات فضای ذخیره‌سازی و ورودی/خروجی
بیشتر ورودی/خروجی Cassandra ترتیبی است، اما مواردی وجود دارد که به ورودی/خروجی تصادفی نیاز دارید. مثال آن خواندن «جدول‌های رشته‌ای مرتب‌شده» درطول عملیات خواندن است. «درایو حالت جامد» (SSD) سازوکار ذخیره‌سازی توصیه‌شده برای Cassandra است، زیرا زمان‌های پاسخ با تأخیر بسیار پایین برای عملیات خواندن تصادفی ارائه می‌دهد و درعین‌حال عملکرد نوشتن ترتیبی کافی برای عملیات فشرده‌سازی فراهم می‌کند. تکثیر نیز در اینجا مورد توجه قرار می‌گیرد.
بسیاری از نمونه‌های AWS EC2 دارای فضای ذخیره‌سازی محلی هستند که در آن، درایو سخت‌افزاری به‌صورت فیزیکی به سخت‌افزاری که نمونه EC2 در آن میزبانی می‌شود متصل است. Apigee توصیه می‌کند هنگام اجرای Cassandra در محیط تولید، از هر دو فروشگاه SSD و نمونه استفاده کنید. وقتی از نوع نمونه‌ای با بیش‌از ۱ SSD استفاده می‌کنید، می‌توانید از RAID0 برای دریافت توان عملیاتی و ظرفیت ذخیره‌سازی بیشتر استفاده کنید.
الزامات شبکه
Cassandra از پروتکل Gossip برای تبادل اطلاعات با گره‌های دیگر درباره توپولوژی شبکه استفاده می‌کند. استفاده از Gossip به‌علاوه ماهیت توزیع‌شده Cassandra — که شامل صحبت کردن با گره‌های متعدد برای عملیات خواندن و نوشتن می‌شود — منجر به انتقال داده‌های زیادی ازطریق شبکه می‌شود. Apigee توصیه می‌کند از «نوع نمونه» با حداقل پهنای باند شبکه ۱ گیگابیت در ثانیه و بیشتر از ۱ گیگابیت در ثانیه برای سیستم‌های تولید استفاده کنید.
از VPC با CIDR از /16 استفاده کنید. ازآنجایی‌که زیرشبکه‌ها در AWS نمی‌توانند بیش‌از ۱ «منطقه دردسترس» را پوشش دهند، Apigee توصیه‌های زیر را ارائه می‌دهد:
- ایجاد ۱ زیرشبکه برای هر «منطقه دردسترس بودن» (AZ)
- برای نصب Apigee، از ۳ زیرشبکه خصوصی استفاده کنید و در هر منطقه دردسترس‌پذیری یک گره Cassandra داشته باشید. این ۳ زیرشبکه باید بلوک‌های CIDR کافی برای تطبیق با گسترش افقی خوشه Cassandra داشته باشند.
- ۳ زیرشبکه عمومی را با NAT اختصاصی برای Cassandra پیکربندی کنید تا بتواند با اینترنت برای بارگیری نرم‌افزار و به‌روزرسانی‌های امنیتی ارتباط برقرار کند.
برخلاف معماری‌های قدیمی اصلی-فرعی، Cassandra معماری بدون اصلی دارد که در آن همه گره‌ها نقش یکسانی دارند، بنابراین نقطه شکست واحدی وجود ندارد. برای فعال کردن دردسترس بودن بالا، گره‌های Cassandra را در چندین «منطقه دردسترس بودن» پخش کنید. با توزیع گره‌ها در «مناطق دردسترس»، درصورت بروز فاجعه می‌توانید همچنان دردسترس بودن و زمان کار را حفظ کنید.
انتخاب خانواده نمونه
هنگام بررسی الزامات CPU در Cassandra، توجه به این نکته مفید است که حجم کاری سنگین درج در Cassandra قبل‌از اینکه محدود به IO شود، محدود به CPU است. به‌عبارت دیگر، همه عملیات نوشتن به گزارش تعهد می‌رود، اما Cassandra در نوشتن بسیار کارآمد است و واحد پردازش مرکزی عامل محدودکننده می‌شود. Cassandra هم‌زمان‌گرایی بالایی دارد و از تمام هسته‌های واحد پردازش مرکزی موجود استفاده می‌کند.
Apigee توصیه می‌کند از خانواده نمونه‌ای استفاده کنید که هم واحد پردازش مرکزی و هم حافظه را به‌صورت متوازن داشته باشد. به‌طور خاص، توصیه می‌کنیم درصورت دردسترس بودن در منطقه AWS خود از نمونه‌های خانواده C5 استفاده کنید و C3 را به‌عنوان گزینه جایگزین درنظر بگیرید. در برخی موارد، 4xlarge نمونه بهینه در هر دو خانواده است که بهترین قیمت/عملکرد را ارائه می‌دهد.
Apigee همچنین توصیه می‌کند از یک اجاره پیش‌فرض برای نمونه‌های Cassandra استفاده کنید. وقتی به بیش‌از ۱ نمونه در هر «منطقه دردسترس» مقیاس‌بندی می‌کنید، اگر اجاره را روی اختصاصی تنظیم کنید، احتمالاً همه نمونه‌های Cassandra شما روی سخت‌افزار زیربنایی یکسانی قرار می‌گیرند. بنابراین، وقتی سخت‌افزار ازکار می‌افتد، احتمالاً همه نمونه‌هایتان را در آن «منطقه دردسترس‌پذیری» ازدست خواهید داد.
خلاصه توصیه
جدول زیر توصیه‌های Apigee را برای استفاده از AWS با Apigee Edge for Private Cloud خلاصه می‌کند:
| خانواده نمونه | C5d (ترجیحی) یا C3 |
| نوع نمونه | C(x).4xlarge |
| فروشگاه نمونه | SSD (فضای ذخیره‌سازی محلی) با RAID0 |
| نوع اجاره | پیش‌فرض |
| جای آگهی گره | ۱ گره Cassandra در هر منطقه دردسترس |
| VPC و Subnet | ۱ زیرشبکه در هر منطقه دردسترس و ۱ VPC در هر منطقه |
برای اطلاعات بیشتر، به انواع نمونه Amazon مراجعه کنید.