با انتشار سرویس Red Hat OpenStack بر روی OpenShift، یک تغییر عمده در ساختار و معماری وجود دارد که نحوه استقرار و مدیریت خدمات OpenStack را تغییر می‌دهد. OpenStack از Containerهای سنتی در لینوکس Red Hat Enterprise به یک معماری مبتنی بر Pod پیشرفته انتقال داده شده است.
سرویس‌های Red Hat OpenStack بر روی OpenShift بر مبنای یک OpenShift cluster در معماری جدید، OpenShift clusterپیاده‌سازی شده بر مبنای Red Hat CoreOS است. Red Hat Openshiftیک زیربنای قدرتمند برای برنامه‌های کاربردی و میکروسرویس‌های Containerized فراهم می‌کند. CoreOSیک توزیع لینوکس است که برای Workloadهای Container بهینه‌شده است و اکنون به‌عنوان سیستم‌عامل برای OpenShift cluster عمل می‌کند.
در OpenShift cluster، سرویس‌های OpenStack Red Hat در OpenShift به‌صورت pod پیاده‌سازی می‌شوند، استفاده از انعطاف‌پذیری و مقیاس‌پذیری Kuberneteهای orchestration. هر جزء، ازجمله خدماتی مانند Nova ،Neutron Cinder و Keystone یک pod شخصی است که امکان استفاده کارآمد از منابع و مدیریت ساده آن را فراهم می‌کند.
این مدل پیاده‌سازی مبتنی بر pod مزایای متعددی نسبت به استقرار کانتینری شده سنتی دارد. با استفاده از ابزارهای اولیه Kuberneteها مانند پیاده‌سازی، سرویس‌ها و podها، کنترل دقیقی بر چرخه عمر سرویس‌های OpenStack به دست می‌آید. قابلیت‌های داخلی برای توسعه دادن، اجرای به‌روزرسانی‌ها و حتی self-healing در دسترس قرا می‌گیرد.
بیشتر بخوانید: پلتفرم خودکارسازی Red Hat Ansible چیست؟ چه مزایایی دارد
data plane در لینوکس Red Hat Enterprise
درحالی‌که کنترل پلین در OpenShift cluster تغییر شکل می‌دهد، data plane همچنان از لینوکس Red Hat Enterprise یا RHEL استفاده می‌کند. Data plane شامل زیرساخت مجازی شده است که در آن سرویس‌های OpenStack Red Hat در نمونه‌های OpenShift ایجاد و کنترل می‌شود.
معرفی مکانیسم استراتژی Adoption
انتقال از پلتفرم Red Hat OpenStack ورژن 17.1 به سرویس‌های Red Hat OpenStack در OpenShift نیازمند یک رویکرد دقیق است. برخلاف upgradeهای سنتی که در محل انجام می‌شوند، این تکامل مستلزم اتخاذ یک مکانیسم استراتژیک Adoption می باشد.
پیاده‌سازی Side-by-side
مهم‌ترین بخش این جابجایی در Control Plane نهفته است، جایی که تغییر از اجرای به‌عنوان Containerها در RHEL به podها در OpenShift نشان‌دهنده انحراف از روش‌های upgrade مرسوم است. برای رسیدگی به پیچیدگی‌های موجود، مکانیسم استراتژی Adoption استراتژی پیاده‌سازی Side-by-side را انتخاب می‌کند. این رویکرد امکان همزیستی هر دو پیاده‌سازی Red Hat OpenStack Platform 17.1 و سرویس‌های جدید Red Hat OpenStack را در محیط OpenShift فراهم می‌کند.
یکی از مزایای قابل‌توجه حفظ کنترل پلین های مبدأ و هدف، توانایی بازگشت به محیط پلتفرم Red Hat OpenStack ورژن 17.1 در صورت بروز مشکل غیرمنتظره در طول Upgrade است. انتقال در محل Data Plane تداوم و پایداری را تضمین می‌کند و این اجازه را به سازمان‌ها می‌دهد تا داده‌ها و بارهای کاری را به‌طور یکپارچه و بدون به خطر انداختن عملکرد یا دسترس‌پذیری به محیط جدید انتقال دهد. این مکانیسم ایمنی، آرامش خاطر را به امین‌ها ارائه می‌دهد و خطر را کاهش می‌دهد.
مراحل کلیدی در مکانیسم سازگاری
OpenShift CP جدید برای سرویس‌های Red Hat OpenStack در OpenShift مبتنی بر Red Hat OpenShift 4.16 است و خدمات OpenStack Red Hat در اپراتورهای OpenShift از پیش نصب‌شده است. شامل موارد زیر:
NMstate ،MetalLB ،Cert-manager و اپراتور Baremetal (Metal3)
مقدمات استراتژی Adoption
در مرحله آماده‌سازی Adoption، اپراتورها اطلاعات زیر را از محیط موجود پلتفرم Red Hat OpenStack 17.1 استخراج می‌کنند:
• پیکربندی سرویس پلتفرم Red Hat OpenStack ورژن 17.1: در طی هر مرحله از Adoption سرویس به کنترل پلین منتقل می‌شود
• پیکربندی شبکه: آدرس‌های تخصیص داده‌شده در قالب‌های شبکه overcloud و os-net-config در منابع مرسوم Dataplane وارد می‌شوند. این تنظیمات در طول هر سرویس Adoption و در طول Adoption دیتا پلین به کنترل پلین انتقال داده می‌شوند.
برای مشاوره رایگان جهت (باز)طراحی امنیت شبکه و یا انجام تست نفوذ مطابق با الزامات افتا با کارشناسان شرکت APK تماس بگیرید. |
درنهایت، گروهی از متغیرهای سطحی را با اطلاعاتی در مورد Database اصلی، محاسبه سرویس Cell Mappingها و نام میزبان سرویس‌های محاسباتی تعریف می‌کند. این اطلاعات بعداً باهدف تأیید در طول فرآیند Adoption استفاده می‌شوند.
انتقال پایگاه‌های داده به ControlPlane
در حالت اولیه، اپراتور OpenStackControlPlane را با خدمات پایه مستقرشده و همه سرویس‌های OpenStack غیرفعال می‌سازد. این پایه و اساس هواپیمای کنترل است. منبع سفارشی یا CR با خدمات پایه مستقرشده و همه سرویس‌های OpenStack غیرفعال شده است. این پایه و اساس ControlPlan است. قبل از شروع انتقال Database، باید خدمات Red Hat OpenStack را در سرویس‌های OpenShift در Nodeها کنترلر متوقف کنید. این‌یک گام مهم برای جلوگیری از ناهماهنگی درداده‌های منتقل شده برای رویه Adoption دیتابیس ناشی از تغییرات منابع پس از کپی شدن پایگاه داده در پیاده‌سازی جدید است.
توقف برخی از سرویس‌ها آسان است، زیرا آن‌ها فقط عملیات غیرهمزمان کوتاهی را انجام می‌دهند، اما سایر سرویس‌ها به‌سختی متوقف می‌شوند زیرا عملیات هم‌زمان یا پیوسته‌ای را انجام می‌دهند که ممکن است بخواهید به‌جای لغو آن‌ها، آن‌ها را تکمیل کنید. سپس، اپراتور پایگاه‌های داده را از استقرار اولیه OpenStack به نمونه‌های MariaDB در ;کلاستر OpenShift منتقل می‌کند.
بیشتر بخوانید: بررسی آینده داده های امنیتی Red Hat
مراحل بعدی عبارت‌اند از:
- مستقرسازی Adapion Helper pod mariadb-copy-data
- یک Dump از پایگاه داده‌های اصلی ایجاد کنید
- پایگاه داده‌ها را از فایل‌های .sql در صفحه کنترل MariaDB بازیابی کنید
درنهایت Mariadb-copy-data pod باید حذف شود.
- 1Adapion Helper pod ovn-copy-data را مستقر کنید
- یک نسخه پشتیبان از پایگاه داده‌های OVN ایجاد کنید
- سرویس‌های پایگاه داده OVN کنترل پلین را قبل از واردکردن شروع کنید، کنترل‌کننده شمالی/ovn را متوقف کنید پایگاه داده را برای فایل‌های پشتیبان ارتقا دهید
- نسخه پشتیبان پایگاه داده را به سرورهای پایگاه داده OVN کنترل پلین بازیابی کنید
- درنهایت، می‌توانید سرویس ovn-northd را راه‌اندازی کنید که پایگاه‌های داده OVN Northbound و Southbound را همگام نگه می‌دارد. همچنین، ovn-controller را فعال کنید
Adopting خدمات OpenStack Red Hat در سرویس‌های کنترل پلین OpenShift
گام بعدی این است که خدمات Red Hat OpenStack را در سرویس‌های OpenShift یکی‌یکی استقرار دهید. در این مثال، فرآیند سرویس هویت Keystone adoption به‌صورت زیر است:
- برای استقرار سرویس Identity، OpenStack Control Plane را پیاده‌سازی کنید
- در حین استقرار keystone، keystone -db-sync pod ایجاد می‌شود.
این pod تشخیص می‌دهد که طرح پایگاه داده مربوط به نسخه قبلی است و فرآیند پیشبرد سریع را از طریق 4 نسخه انجام می‌دهد: Wallaby → Xena → Yoga → Zed → Antelope
- پس از اجرای Keystone-db-sync، پایگاه داده Keystone از طرح Antelope DB استفاده می‌کند.
- اپراتور از pod openstackclient برای اجرای دستورهای openstack استفاده می‌کند تا سرویس‌ها و endpoints را که هنوز به ControlPlane قدیمی اشاره می‌کنند پاک کند.
همه سرویس‌های OpenStack Red Hat در سرویس‌های OpenShift کنترل پلین از روند مشابهی پیروی می‌کنند.
اگر در حین adoption سرویس‌های OpenStack Red Hat در خدمات ControlPlane OpenShift با مشکلی مواجه شدید، می‌توانید استراتژی Adoption کنترل پلین را به عقب برگردانید.
روند برگشت از مراحل زیر تشکیل‌شده است:
- عملکرد منبع ControlPlane را بازیابی کنید
- حذف کنترل پلین مقصد که به‌طور جزئی یا کامل پیاده‌سازی شده است اتخاذ صفحه داده
- بخش دوم فرآیند Adoption ، پذیرش دیتا پلین است.
ابتدا باید سرویس‌های backend باقی‌مانده را در ControlPlane متوقف کنید.
قبل از adoption خدمات محاسباتی، اپراتور باید یک منبع OpenStack Dataplane Deployment ایجاد کند.
این پیاده‌سازی باید شامل Playbook پیش از Adoption و تأیید اعتبار باشد که به‌عنوان OpenStackDataplaneService مهیا شده است.
پس از پیاده‌سازی، یک کار Ansible Execution Environment به‌طور خودکار راه‌اندازی می‌شود. این کار بررسی‌های اعتبار سنجی زیر را اجرا می‌کند:
• اعتبار سنجی نام میزبان
• اعتبار Kernel argument
• بررسی مشخصات تنظیم‌شده
در اینجا مراحل موردنیاز آمده است:
1. منابع NetConfig مدیریت آدرس IP (IPAM) را با استفاده از پیکربندی شبکه جمع‌آوری‌شده در مرحله اول و هرگونه منابع سفارشی مرتبط با EDPM که در استقرار Greenfield استفاده می‌شود، پیکربندی کنید
2. یک سرویس nova-compute-extra-config ایجاد کنید
که در آن disable_compute_service_check_for_ffu=true.
این فقط برای تسهیل ارتقاء سریع به جلو FFU است که در آن خدمات کنترلی جدید قبل از اینکه Nodeهای رایانشی بتوانند سابقه سرویس خود را به‌روز کنند، شروع می‌شوند.
در یک FFU، recordهای سرویس در پایگاه داده بیش از یک نسخه قدیمی هستند تا زمانی که Nodeهای رایانشی راه‌اندازی شوند، اما خدمات کنترل باید ابتدا آنلاین باشند.
3. منابع سفارشی OpenStackDataPlaneNodeSet و OpenStack DataPlane Deployment را مستقر کنید.
کارهای Ansible Execution Environment یا EE برای اجرای Playbooks برای هر سرویس راه‌اندازی می‌شوند: bootstrap، download-cache، پیکربندی-شبکه و غیره
- سرویس bootstrap سیستم RHEL را به مخازن RHOSP18 هدایت می‌کند و حداقل بسته‌های موردنیاز مانند openstack-selinux را نصب می‌کند
- OpenStack DataPlaneServices نیزcontainer های Storage، محاسبه و شبکه‌سازیOSP 17.1 را با Containerهای RHOSP18 جایگزین می‌کند.
درنهایت، Upgradeهای ارتقاء پیش‌فرض به جلو را برای سرویس‌های Control Plane محاسباتی با تنظیم flag disable_compute_service_check_for_ffu=false حذف کنید و برای تکمیل ارتقاء سریع روبه‌جلو، انتقال‌های آنلاین database محاسبه را اجرا کنید. در این مرحله، تمام محتوای پلتفرم OpenStack Red Hat در cluster به خدمات Red Hat OpenStack در OpenShift ارتقا یافته است. شما یک محیط پشتیبانی شده دارید.
