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