به روز رسانی Apigee Edge 4.52.02 یا 4.53.00 به 4.53.01

Apigee از ارتقاء مستقیم Edge برای Private Cloud از نسخه ۴.۵۲.۰۲ یا ۴.۵۳.۰۰ به نسخه ۴.۵۳.۰۱ پشتیبانی می‌کند. این صفحه نحوه انجام چنین ارتقاءهایی را شرح می‌دهد.

برای مرور کلی مسیرهای ارتقاء سازگار، به ماتریس سازگاری ارتقاء برای نسخه‌های Edge برای Private Cloud مراجعه کنید.

چه کسی می‌تواند به‌روزرسانی را انجام دهد؟

شخصی که به‌روزرسانی را اجرا می‌کند باید همان شخصی باشد که در ابتدا Edge را نصب کرده است، یا شخصی که با دسترسی root اجرا می‌کند.

پس از نصب Edge RPMها، هر کسی می‌تواند آنها را پیکربندی کند.

کدام اجزا را باید به‌روزرسانی کنید؟

شما باید تمام اجزای Edge را به‌روزرسانی کنید. Edge از تنظیماتی که شامل اجزایی از چندین نسخه باشد، پشتیبانی نمی‌کند.

پیش‌نیازها را به‌روزرسانی کنید

قبل از ارتقاء Apigee Edge، از پیش نیازهای زیر اطمینان حاصل کنید:

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

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

• مطمئن شوید که Edge در حال اجرا است
  با استفاده از دستور زیر، مطمئن شوید که Edge در طول فرآیند به‌روزرسانی فعال و در حال اجرا است:

  /opt/apigee/apigee-service/bin/apigee-all status

• پیش‌نیازهای کاساندرا را تأیید کنید
  

  اگر قبلاً از نسخه قدیمی‌تر Edge for Private Cloud به نسخه ۴.۵۲.۰۲ ارتقا داده‌اید و اکنون قصد دارید به نسخه ۴.۵۳.۰۱ ارتقا دهید، مطمئن شوید که مراحل مورد نیاز پس از ارتقا برای Cassandra را تکمیل کرده‌اید. این مراحل در مستندات ارتقا به نسخه ۴.۵۲.۰۲ شرح داده شده است و همچنین در بخش پیش‌نیازهای ارتقا به Cassandra ذکر شده است. اگر مطمئن نیستید که آیا این مراحل در طول ارتقا قبلی تکمیل شده‌اند یا خیر، قبل از ادامه ارتقا به نسخه ۴.۵۳.۰۱، آنها را دوباره تکمیل کنید.

• پیکربندی کلیدها و گواهی‌های IDP در Edge برای Private Cloud 4.53.01
  

  در Edge برای Private Cloud 4.53.01، کلیدها و گواهی‌های IDP مورد استفاده در کامپوننت apigee-sso اکنون از طریق یک keystore پیکربندی می‌شوند. شما باید کلید و گواهی‌ای را که قبلاً استفاده می‌کردید، به یک keystore منتقل کنید. برای مراحل دقیق قبل از به‌روزرسانی کامپوننت SSO، مراحل موجود در بخش «مراحل به‌روزرسانی Apigee SSO از نسخه‌های قدیمی‌تر» را دنبال کنید.

• الزامات پایتون
  قبل از اقدام به ارتقا، مطمئن شوید که همه گره‌ها، از جمله گره‌های کاساندرا، پایتون ۳ را نصب کرده‌اند.

چه مراحل خاصی را برای ارتقا باید در نظر گرفت

برای ارتقاء به Edge برای Private Cloud 4.53.01، مراحل خاصی را برای ارتقاء نرم‌افزارهای خاص در نظر بگیرید. مراحل لازم به نسخه فعلی شما بستگی دارد. برای نرم‌افزارهای مختلفی که نیاز به مراحل تکمیلی دارند، به جدول زیر مراجعه کنید و دستورالعمل‌های دقیق هر کدام را دنبال کنید. پس از انجام کارهای لازم، برای ادامه فرآیند ارتقاء به روش اصلی ارتقاء برگردید.

پس از انجام مراحل لازم بر اساس نسخه خود، برای ادامه به روال اصلی ارتقا برگردید.

انتشار خودکار تنظیمات ویژگی

اگر با ویرایش فایل‌های .properties در /opt/apigee/customer/application ‎، ویژگی‌هایی را تنظیم کرده باشید، این مقادیر با به‌روزرسانی حفظ می‌شوند.

ارتقاء به OpenLDAP 2.6 الزامی است

در اینجا روش گام به گام برای ارتقاء سرویس LDAP زیربنایی Apigee Edge for Private Cloud از OpenLDAP 2.4 قدیمی به OpenLDAP 2.6 آمده است. این ارتقاء یک الزام اجباری برای به‌روزرسانی به Apigee Edge for Private Cloud نسخه ۴.۵۳.۰۱ و بالاتر است. این ارتقاء برای همه توپولوژی‌های استقرار LDAP Apigee قابل اجرا است: تک سروری، فعال-غیرفعال و فعال-فعال (چند سروری).

پیش‌نیازها و ملاحظات

• توجه داشته باشید که در طول فرآیند ارتقاء LDAP، APIهای مدیریتی و در نتیجه، رابط کاربری Apigee در تمام مناطق کاملاً از دسترس خارج خواهند شد. تمام وظایف مدیریتی - مانند مدیریت کاربران، نقش‌ها، برنامه‌ها و سازمان‌ها - با شکست مواجه شده و باید متوقف شوند. هیچ تاثیری بر پردازش ترافیک پروکسی API شما نخواهد داشت. لطفاً قبل از ادامه ارتقاء LDAP، مطمئن شوید که تمام سرورهای مدیریت لبه و رابط کاربری لبه را خاموش کرده‌اید.

• پشتیبان‌گیری بسیار مهم است: تهیه‌ی یک پشتیبان کامل و معتبر از داده‌های LDAP موجود شما غیرقابل انکار است. ادامه‌ی کار بدون یک پشتیبان‌گیری معتبر باعث از دست رفتن غیرقابل برگشت داده‌ها خواهد شد. پشتیبان‌گیری باید زمانی آغاز شود که سرویس LDAP هنوز در حال اجرا است تا یک تصویر لحظه‌ای ثابت و لحظه‌ای از داده‌های LDAP ثبت شود. پشتیبان‌گیری برای انجام ارتقاء واقعی ضروری است. بدون پشتیبان‌گیری، شما نه قادر به اجرای ارتقاء خواهید بود و نه می‌توانید به عقب برگردید زیرا مراحل ارتقاء شامل پاک کردن داده‌های LDAP می‌شود.

آماده‌سازی و نصب (تمام سرورهای LDAP)

مراحل این بخش (مرحله ۲ تا مرحله ۵) برای همه توپولوژی‌های استقرار LDAP یکسان است. این اقدامات باید روی هر سروری که مؤلفه apigee-openldap در آن نصب شده است، صرف نظر از نقش آن، انجام شود.

1. لطفاً قبل از ادامه‌ی ارتقاء LDAP، مطمئن شوید که تمام سرورهای مدیریت لبه و رابط کاربری لبه را خاموش کرده‌اید.

   apigee-service edge-management-server stop
   apigee-service edge-ui stop

2. پشتیبان‌گیری از داده‌های LDAP موجود

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

   • دستور پشتیبان‌گیری را اجرا کنید. این عمل یک بایگانی پشتیبان‌گیری با مهر زمانی در دایرکتوری /opt/apigee/backup/openldap ایجاد می‌کند.

     apigee-service apigee-openldap backup

   • دریافت تعداد کل رکوردها: تعداد رکوردهای موجود در دایرکتوری خود را برای اعتبارسنجی پس از ارتقا ثبت کنید (تعداد رکوردها باید در تمام سرورهای LDAP مطابقت داشته باشد). این یک بررسی سلامت است.

     # Note: Replace 'YOUR_PASSWORD' with your current LDAP manager password.
     ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" \
     -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l

3. متوقف کردن LDAP و پاک کردن دایرکتوری‌های داده

   این مرحله باید روی همه سرورهای LDAP انجام شود. به دلیل تغییر عمده نسخه و تفاوت‌های ساختاری اساسی، این کار اجباری است. یک دایرکتوری تمیز تضمین می‌کند که هیچ تداخلی وجود ندارد. وقتی همه سرورهای LDAP متوقف شوند، اختلال در APIهای مدیریتی و رابط کاربری آغاز می‌شود.

   • سرویس LDAP را متوقف کنید.

     apigee-service apigee-openldap stop

   • دایرکتوری‌های قدیمی داده‌ها و پیکربندی LDAP را به‌طور دائم حذف کنید.

     rm -rf /opt/apigee/data/apigee-openldap/*

4. نسخه جدید LDAP را نصب و پیکربندی کنید

   در تمام سرورهای LDAP، از اسکریپت‌های استاندارد Apigee برای دانلود و نصب نسخه جدید کامپوننت استفاده کنید.

   • نصب کامپوننت جدید LDAP: اسکریپت به‌روزرسانی، فایل پیکربندی شما را می‌خواند و بسته جدید apigee-openldap را نصب می‌کند.

     /opt/apigee/apigee-setup/bin/update.sh -c ldap -f /opt/silent.conf

   • نسخه جدید LDAP را اعتبارسنجی کنید: پس از اتمام نصب، پروفایل را مجدداً بارگذاری کنید تا مطمئن شوید که نسخه جدید LDAP به درستی نصب شده است.

     source ~/.bash_profile
     ldapsearch -VV
     Expected output:
     ldapsearch: @(#) $OpenLDAP: ldapsearch 2.6.7

5. قبل از بازیابی اطلاعات، LDAP را روی همه سرورها متوقف کنید

   این یک مرحله همگام‌سازی حیاتی است. قبل از بازیابی نسخه پشتیبان، باید مطمئن شوید که سرویس LDAP تازه نصب شده روی همه سرورها متوقف شده است. در هر سرور LDAP، دستورات زیر را اجرا کنید:

   apigee-service apigee-openldap stop
   rm -rf /opt/apigee/data/apigee-openldap/ldap/*

6. بازیابی داده‌های LDAP

   استراتژی این است که نسخه پشتیبان را روی اولین سرور فعال بازیابی کنیم. سپس این سرور به عنوان منبع حقیقت عمل می‌کند و داده‌ها را در یک پیکربندی چند سروری برای همتایان خود تکرار می‌کند.

   1. اولین سرور فعال برای بازیابی را شناسایی کنید

      • برای راه‌اندازی تک سرور: این تنها سرور LDAP شماست. می‌توانید مستقیماً به مرحله بعدی بروید.
      • برای تنظیمات فعال-غیرفعال و فعال-فعال: دستور تشخیصی زیر را روی هر سرور LDAP اجرا کنید:

        grep -i '^olcSyncrepl:' /opt/apigee/data/apigee-openldap/slapd.d/cn=config/olcDatabase*\ldif
        Note:
        -If this command returns output, the server is a passive server.
        -If it returns no output, the server is the active server.

   2. بازیابی اطلاعات پشتیبان

      قبل از ادامه، بررسی کنید که مرحله ۵ با موفقیت روی همه سرورهای LDAP انجام شده باشد.

      • در اولین سرور فعالی که در بالا شناسایی کردید، به دایرکتوری پشتیبان بروید.

        cd /opt/apigee/backup/openldap

      • دستور restore را اجرا کنید. اکیداً توصیه می‌کنیم برای جلوگیری از بازیابی نسخه ناخواسته یا قدیمی‌تر، دقیقاً همان زمان پشتیبان‌گیری مرحله ۲ را مشخص کنید.

        # To restore a specific backup (recommended):
        apigee-service apigee-openldap restore 2025.08.11,23.34.00
        
        # To restore the latest available backup by default:
        apigee-service apigee-openldap restore

      • پس از اتمام موفقیت‌آمیز فرآیند بازیابی، سرویس LDAP را روی اولین سرور فعال شروع کنید.

        apigee-service apigee-openldap start

7. شروع سرورهای LDAP باقی مانده

   اگر چندین سرور راه‌اندازی کرده‌اید، روی هر یک از سرورهای LDAP، سرویس را شروع کنید:

   apigee-service apigee-openldap start

8. اعتبارسنجی نهایی

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

   • دستور اعتبارسنجی را روی تمام سرورهای LDAP اجرا کنید. تعداد رکوردها باید در تمام سرورها یکسان باشد و با تعداد رکوردهای ثبت شده در مرحله 2 مطابقت داشته باشد.

   # Note: Replace 'YOUR_PASSWORD' with your LDAP manager password.
   ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" \
   -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l

   • پس از تأیید صحت و سازگاری داده‌ها، ارتقاء LDAP شما کامل شده است. اکنون می‌توانید طبق روال استاندارد ارتقاء سازمان خود ، سرور مدیریت لبه و رابط کاربری لبه و سایر اجزای وابسته را راه‌اندازی کنید.

ارتقاء الزامی به کاساندرا ۴.۰.۱۸

Apigee Edge برای Private Cloud نسخه ۴.۵۳.۰۱ شامل ارتقاء کاساندرا به نسخه ۴.۰.۱۸ است.

ارتقاها و بازگشت به نسخه قبلی

• ارتقا از Cassandra 3.11.X به Cassandra 4.0.X فرآیندی روان است. Cassandra 4.0.X که با Edge for Private Cloud 4.53.00 منتشر شده است، با اجزای زمان اجرا و مدیریت Private Cloud 4.52.02 سازگار است.
• بازگشت مستقیم و درجا از کاساندرا ۴.۰.X به ۳.۱۱.X امکان‌پذیر نیست. بازگشت به نسخه قبلی با استفاده از کپی‌ها یا نسخه‌های پشتیبان، روشی پیچیده است و ممکن است شامل از کارافتادگی و/یا از دست رفتن داده‌ها شود. عیب‌یابی مشکلات و ارتقا به کاساندرا ۴.۰.X نسبت به بازگشت به نسخه قبلی ارجحیت دارد.
• قبل از اقدام به ارتقا، آشنایی با رویه‌های بازگشت به نسخه قبلی (rollback) بسیار مهم است. در نظر گرفتن جزئیات بازگشت به نسخه قبلی در طول ارتقا برای اطمینان از در دسترس بودن مسیرهای مناسب بازگشت به نسخه قبلی بسیار مهم است.

مرکز داده واحد

ارتقاء کاساندرا از نسخه ۳.۱۱.X به ۴.۰.X در یک مرکز داده واحد، بدون مشکل انجام می‌شود، اما بازگشت به نسخه قبلی پیچیده است و ممکن است منجر به از کار افتادگی و از دست رفتن داده‌ها شود. برای بارهای کاری عملیاتی، اکیداً توصیه می‌شود قبل از شروع ارتقاء ، یک مرکز داده جدید با حداقل گره‌های کاساندرا موجود در مرکز داده جدید اضافه کنید . این کار امکان بازگشت به نسخه قبلی کاساندرا را بدون از دست دادن داده‌ها یا اختلال در ترافیک API شما فراهم می‌کند. این مرکز داده اضافی را می‌توان پس از اتمام ارتقاء یا رسیدن به نقطه بازرسی ۲، از رده خارج کرد.

اگر اضافه کردن یک مرکز داده جدید امکان‌پذیر نباشد اما قابلیت بازگشت به نسخه قبلی همچنان مورد نظر باشد، برای بازیابی Cassandra 3.11.X به پشتیبان‌گیری نیاز خواهد بود. با این حال، این روش احتمالاً شامل زمان از کارافتادگی و از دست رفتن داده‌ها می‌شود.

مراکز داده چندگانه

مدیریت چندین مرکز داده با Edge for Private Cloud 4.52.02 انعطاف‌پذیری بیشتری برای بازگرداندن تنظیمات به نسخه‌های قبلی در طول ارتقا به Edge for Private Cloud 4.53.00 ارائه می‌دهد.

• بازگرداندن نسخه‌های قبلی به نسخه‌های قبلی به این نسخه، منوط به این است که حداقل یک مرکز داده، نسخه قدیمی‌تر کاساندرا (3.11.X) را اجرا کند.
• اگر کل کلاستر کاساندرای شما به نسخه ۴.۰.X ارتقا یافته است، نباید به کاساندرای ۳.۱۱.X برگردید. شما باید به استفاده از نسخه جدیدتر کاساندرا با سایر اجزای Private Cloud 4.53.00 یا ۴.۵۲.۰۲ ادامه دهید.

روش ارتقاء توصیه شده

1. ارتقاء یک مرکز داده کاساندرا در یک زمان: با ارتقاء گره‌های کاساندرا به صورت جداگانه در یک مرکز داده شروع کنید. قبل از ادامه به مرکز داده بعدی، ارتقاء تمام گره‌های کاساندرا را در یک مرکز داده کامل کنید.
2. مکث و اعتبارسنجی: پس از ارتقاء یک مرکز داده، مکث کنید تا مطمئن شوید که خوشه ابر خصوصی شما، به ویژه مرکز داده ارتقا یافته، به درستی کار می‌کند.
3. به یاد داشته باشید: فقط در صورتی می‌توانید به نسخه قبلی کاساندرا برگردید که حداقل یک مرکز داده هنوز نسخه قدیمی‌تر را اجرا کند.
4. حساس به زمان: اگرچه می‌توانید برای مدت کوتاهی (چند ساعت توصیه می‌شود) برای اعتبارسنجی عملکرد، مکث کنید، اما نمی‌توانید به طور نامحدود در حالت نسخه مختلط باقی بمانید. دلیل این امر آن است که یک خوشه کاساندرا غیر یکنواخت (با گره‌هایی در نسخه‌های مختلف) محدودیت‌های عملیاتی دارد.
5. آزمایش کامل: شرکت Apigee اکیداً توصیه می‌کند قبل از ارتقاء مرکز داده بعدی، آزمایش جامعی از عملکرد و کارایی انجام شود. پس از ارتقاء همه مراکز داده، بازگشت به نسخه قبلی غیرممکن است.

بازگرداندن به حالت اولیه به عنوان یک فرآیند دو نقطه کنترلی

1. نقطه بررسی ۱: حالت اولیه، با تمام اجزا روی نسخه ۴.۵۲.۰۲. تا زمانی که حداقل یک مرکز داده کاساندرا روی نسخه قدیمی‌تر باقی بماند، بازگشت کامل امکان‌پذیر است.
2. نقطه بررسی ۲: پس از اینکه تمام گره‌های کاساندرا در تمام مراکز داده به‌روزرسانی شدند، می‌توانید به این حالت برگردید، اما نمی‌توانید به نقطه بررسی ۱ برگردید.

مثال

یک خوشه دو مرکز داده (DC) را در نظر بگیرید:

1. حالت شروع: گره‌های کاساندرا در هر دو DC روی نسخه 3.11.X هستند. همه گره‌های دیگر روی Edge برای Private Cloud نسخه 4.52.02 هستند. فرض کنید سه گره کاساندرا در هر DC وجود دارد.
2. ارتقاء DC-1: سه گره کاساندرا را در DC-1 یکی یکی ارتقا دهید.
3. مکث و اعتبارسنجی: مکث کنید تا مطمئن شوید که خوشه، به ویژه DC-1، به درستی کار می‌کند (عملکرد و کارایی را بررسی کنید). می‌توانید با استفاده از گره‌های کاساندرا در DC-2 به حالت اولیه برگردید. به یاد داشته باشید، این مکث باید به دلیل محدودیت‌های یک خوشه کاساندرا با نسخه مختلط، موقتی باشد.
4. ارتقاء DC-2: سه گره کاساندرا باقی مانده در DC-2 را ارتقا دهید. این به عنوان نقطه بازگشت جدید شما تبدیل می‌شود.
5. ارتقاء سایر اجزا: گره‌های مدیریت، زمان اجرا و تجزیه و تحلیل را طبق معمول در تمام مراکز داده، یک گره و یک مرکز داده در یک زمان، ارتقا دهید. در صورت بروز مشکل، می‌توانید به حالت مرحله ۴ برگردید.

پیش‌نیازهای ارتقاء کاساندرا

1. کل خوشه با Cassandra 3.11.16 عملیاتی و کاملاً کاربردی است.
2. استراتژی فشرده‌سازی روی LeveledCompactionStrategy تنظیم شده است (پیش‌نیازی برای ارتقا به نسخه ۴.۵۲.۰۲).

3. تأیید کنید که هر مرحله زیر به عنوان بخشی از ارتقاء اولیه Cassandra 3.11 در Edge برای Private Cloud از نسخه 4.52.02 انجام شده است.

   • دستور post_upgrade در طول ارتقاء قبلی روی هر گره کاساندرا اجرا شد.
   • دستور drop_old_tables در طول ارتقاء قبلی روی کل کلاستر کاساندرا اجرا شد.

اگر مطمئن نیستید که دستورات post_upgrade و drop_old_tables در Cassandra 3.11 هنگام استفاده از Edge برای Private Cloud 4.52.02 اجرا شده‌اند، می‌توانید قبل از اقدام به ارتقا به 4.53.01، با خیال راحت آنها را دوباره اجرا کنید.

مرحله ۱: آماده شدن برای ارتقا

مراحل زیر علاوه بر فایل‌های استانداردی است که معمولاً ایجاد می‌کنید، مانند فایل پیکربندی استاندارد Apigee برای فعال‌سازی ارتقاء اجزا.

1. پشتیبان‌گیری از کاساندرا با استفاده از Apigee
2. در صورت امکان، از گره‌های کاساندرا در ماشین مجازی اسنپ‌شات بگیرید.
3. اطمینان حاصل کنید که پورت ۹۰۴۲ از تمام اجزای Edge برای ابر خصوصی، از جمله سرور مدیریت، پردازنده پیام، روتر، Qpid و Postgres، برای گره‌های کاساندرا در صورت عدم پیکربندی، قابل دسترسی است. برای اطلاعات بیشتر به الزامات پورت مراجعه کنید.

مرحله 2: تمام گره‌های کاساندرا را ارتقا دهید

تمام گره‌های کاساندرا باید در هر مرکز داده، یک به یک و هر بار یک مرکز داده، به‌روزرسانی شوند. بین به‌روزرسانی گره‌ها در یک مرکز داده، چند دقیقه صبر کنید تا مطمئن شوید که یک گره به‌روزرسانی‌شده به‌طور کامل شروع به کار کرده و به خوشه پیوسته است، قبل از اینکه به‌روزرسانی گره دیگری را در همان مرکز داده ادامه دهید.

پس از ارتقاء تمام گره‌های کاساندرا در یک مرکز داده، قبل از ادامه کار با گره‌ها در مرکز داده بعدی، مدتی (30 دقیقه تا چند ساعت) صبر کنید. در این مدت، مرکز داده‌ای را که به‌روزرسانی شده است، به طور کامل بررسی کنید و مطمئن شوید که معیارهای عملکردی و کارایی خوشه Apigee شما دست نخورده باقی مانده است. این مرحله برای اطمینان از پایداری مرکز داده‌ای که کاساندرا در آن به نسخه 4.0.X ارتقا یافته است، بسیار مهم است، در حالی که بقیه اجزای Apigee در نسخه 4.52.02 باقی می‌مانند.

1. برای ارتقاء یک گره کاساندرا، دستور زیر را اجرا کنید:

   /opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile

2. پس از به‌روزرسانی یک گره، دستور زیر را روی گره اجرا کنید تا قبل از ادامه، برخی اعتبارسنجی‌ها انجام شود:

   /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra validate_upgrade -f configFile

3. خروجی دستور بالا چیزی شبیه به این خواهد بود:

   Cassandra version is verified - [cqlsh 6.0.0 | Cassandra 4.0.18 | CQL spec 3.4.5 | Native protocol v5] 
   Metadata is verified

4. دستور post_upgrade زیر را روی گره کاساندرا اجرا کنید:

   /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra post_upgrade

5. برای بازسازی شاخص‌ها در گره کاساندرا، دستورات nodetool زیر را اجرا کنید:

   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms api_products api_products_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_api_products_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_organization_app_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_end_user app_end_user_app_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_family_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_type_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_parent_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_parent_status_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_status_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms maps maps_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_app_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_consumer_key_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_status_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_request_tokens oauth_10_request_tokens_consumer_key_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_request_tokens oauth_10_request_tokens_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_verifiers oauth_10_verifiers_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_verifiers oauth_10_verifiers_request_token_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_app_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_client_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_refresh_token_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_authorization_codes oauth_20_authorization_codes_client_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_authorization_codes oauth_20_authorization_codes_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_status_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_company_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_developer_email_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_email_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_status_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index cache cache_entries cache_entries_cache_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_operation_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_requesturi_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_responsecode_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_timestamp_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_user_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis a_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis a_org_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_active_rev
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_def_index_template
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_def_method_template
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_latest_rev
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_base_url
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_is_active
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_is_latest
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_org_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_rel_ver
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_rev_num
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_a_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_api_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_ar_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_base_url
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_org_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_r_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_r_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_res_path
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_rev_num
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_a_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_api_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_ar_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_base_url
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_org_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_res_path
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_rev_num
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 schemas s_api_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 schemas s_ar_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 security sa_api_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 security sa_ar_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_a_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_a_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_entity
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_org_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template_auth au_api_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index dek keys usecase_index

   اگر از monetization استفاده می‌کنید، دستورات بازسازی شاخص‌های زیر را که مربوط به فضاهای کلید monetization هستند نیز اجرا کنید:

   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_created_date_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_org_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_updated_date_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_created_date_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_currency_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_dev_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_limit_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_org_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_prod_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_reason_code_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_sub_org_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_company_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_created_at_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_developer_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_lastmodified_at_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_org_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers triggers_env_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers triggers_job_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers triggers_org_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus job_details job_details_job_class_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus job_details job_details_job_group_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus job_details job_details_job_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus org_triggers org_triggers_org_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers_suite triggers_suite_group_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers_suite triggers_suite_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers_suite triggers_suite_suite_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_item notification_service_item_org_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_item notification_service_item_status_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_black_list_item notification_service_black_list_item_org_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_black_list_item notification_service_black_list_item_to_email_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_email_template_item notification_email_template_item_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_email_template_item notification_email_template_item_org_id_idx

مرحله ۳: تمام گره‌های مدیریتی را ارتقا دهید

تمام گره‌های مدیریتی را در تمام مناطق، یکی یکی ارتقا دهید:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

مرحله ۴: تمام گره‌های زمان اجرا را ارتقا دهید

تمام روترها و گره‌های پردازنده پیام را در تمام مناطق، یک به یک ارتقا دهید:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

مرحله ۵: تمام اجزای باقی‌مانده Edge برای Private Cloud 4.53.01 را ارتقا دهید

تمام گره‌های edge-qpid-server و edge-postgres-server باقی‌مانده را در تمام مناطق، یکی یکی ارتقا دهید.

ارتقاء مورد نیاز به Zookeeper 3.8.4

این نسخه از Edge برای Private Cloud شامل ارتقاء به Zookeeper 3.8.4 است. به عنوان بخشی از این ارتقاء، تمام داده‌های Zookeeper به Zookeeper 3.8.4 منتقل خواهند شد.

قبل از ارتقاء Zookeeper، راهنمای نگهداری Zookeeper را مطالعه کنید. اکثر سیستم‌های تولید Edge از خوشه‌ای از گره‌های Zookeeper که در چندین مرکز داده پخش شده‌اند، استفاده می‌کنند. برخی از این گره‌ها به عنوان رأی‌دهنده‌هایی که در انتخاب رهبر Zookeeper شرکت می‌کنند، پیکربندی شده‌اند و بقیه به عنوان ناظر پیکربندی شده‌اند. برای جزئیات بیشتر به بخش «درباره رهبران، دنبال‌کنندگان، رأی‌دهندگان و ناظران» مراجعه کنید. گره‌های رأی‌دهنده یک رهبر انتخاب می‌کنند که پس از آن خود گره‌های رأی‌دهنده به دنبال‌کننده تبدیل می‌شوند.

در طول فرآیند به‌روزرسانی، هنگام خاموش شدن گره رهبر، ممکن است یک تأخیر لحظه‌ای یا عدم موفقیت در نوشتن در Zookeeper رخ دهد. این امر می‌تواند بر عملیات مدیریتی که در Zookeeper نوشته می‌شوند، مانند عملیات استقرار یک پروکسی، و تغییرات زیرساخت Apigee، مانند اضافه یا حذف یک پردازنده پیام و غیره، تأثیر بگذارد. در طول ارتقاء Zookeeper با پیروی از روش زیر، نباید هیچ تأثیری بر APIهای زمان اجرای Apigee (مگر اینکه این APIهای زمان اجرا، APIهای مدیریت را فراخوانی کنند) داشته باشد.

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

پشتیبان بگیرید

از تمام گره‌های Zookeeper نسخه پشتیبان تهیه کنید تا در صورت نیاز به بازگرداندن (rollback) از آنها استفاده کنید. توجه داشته باشید که بازگرداندن، Zookeeper را به حالت اولیه خود، زمانی که نسخه پشتیبان تهیه شده بود، برمی‌گرداند. توجه: هرگونه استقرار یا تغییر زیرساخت در Apigee از زمان تهیه نسخه پشتیبان (که اطلاعات آن در Zookeeper ذخیره می‌شود) در حین بازیابی از بین خواهد رفت.

  /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper backup

اگر از ماشین‌های مجازی استفاده می‌کنید و این قابلیت را دارید، می‌توانید از ماشین‌های مجازی اسنپ‌شات یا پشتیبان تهیه کنید تا در صورت لزوم آنها را بازیابی یا به حالت قبل برگردانید.

شناسایی رهبر، پیروان و ناظران

توجه: دستورات نمونه زیر از ابزار nc برای ارسال داده به Zookeeper استفاده می‌کنند. شما می‌توانید از ابزارهای جایگزین نیز برای ارسال داده به Zookeeper استفاده کنید.

1. اگر روی گره ZooKeeper نصب نشده است، nc را نصب کنید:

     sudo yum install nc

2. دستور nc زیر را روی گره اجرا کنید، که در آن ۲۱۸۱ پورت ZooKeeper است:

     echo stat | nc localhost 2181

   شما باید خروجی مانند زیر را ببینید:

     Zookeeper version: 3.8.4-5a02a05eddb59aee6ac762f7ea82e92a68eb9c0f, built on 2022-02-25 08:49 UTC
     Clients:
      /0:0:0:0:0:0:0:1:41246[0](queued=0,recved=1,sent=0)
     
     Latency min/avg/max: 0/0.2518/41
     Received: 647228
     Sent: 647339
     Connections: 4
     Outstanding: 0
     Zxid: 0x400018b15
     Mode: follower
     Node count: 100597

   در خط Mode خروجی برای گره‌ها، بسته به پیکربندی گره، باید ناظر (observer)، رهبر (leader) یا دنبال‌کننده (follower) (به معنی رأی‌دهنده‌ای که رهبر نیست) را ببینید. توجه: در نصب مستقل Edge با یک گره ZooKeeper، Mode روی مستقل (standalone) تنظیم شده است.

3. مراحل ۱ و ۲ را روی هر گره ZooKeeper تکرار کنید.

ارتقا Zookeeper روی گره‌های ناظر و پیرو

Zookeeper را روی هر یک از گره‌های ناظر و پیرو به شرح زیر ارتقا دهید:

1. همانطور که در به‌روزرسانی به ۴.۵۳.۰۱ توضیح داده شده است، بوت‌استرپ Edge for Private Cloud 4.53.01 را روی یک گره با اتصال اینترنت خارجی دانلود و اجرا کنید. این فرآیند احتمالاً بسته به اینکه گره اتصال اینترنت خارجی دارد یا شما در حال انجام نصب آفلاین هستید، متفاوت خواهد بود.
2. کامپوننت Zookeeper را ارتقا دهید:

     /opt/apigee/apigee-setup/bin/update.sh -c zk -f <silent-config-file>

   توجه: اگر این گره‌ها اجزای دیگری نیز نصب دارند (مانند کاساندرا)، می‌توانید آنها را نیز اکنون ارتقا دهید (مانند cs,zk profile) یا می‌توانید اجزای دیگر را بعداً ارتقا دهید. Apigee توصیه می‌کند که ابتدا Zookeeper را ارتقا دهید و قبل از ارتقاء سایر اجزا، مطمئن شوید که خوشه شما به درستی کار می‌کند.
3. مراحل بالا را روی هر یک از گره‌های ناظر و پیرو Zookeeper تکرار کنید.

خاموش کردن رهبر

پس از ارتقاء همه گره‌های ناظر و پیرو، گره رهبر را خاموش کنید. روی گره‌ای که به عنوان رهبر شناسایی شده است، دستور زیر را اجرا کنید:

  /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper stop

توجه داشته باشید که در طول این رویداد، قبل از انتخاب رهبر جدید، ممکن است تأخیرهای لحظه‌ای یا خرابی در نوشتن در Zookeeper وجود داشته باشد. این امر می‌تواند بر عملیاتی که در Zookeeper نوشته می‌شوند، مانند اقدام به استقرار پروکسی‌ها یا تغییرات زیرساخت Apigee، مانند افزودن یا حذف پردازنده‌های پیام و غیره، تأثیر بگذارد.

تأیید کنید که رهبر جدید انتخاب شده است

با استفاده از مراحل ذکر شده در بخش شناسایی رهبر، پیروان و ناظران در بالا، پس از متوقف کردن رهبر موجود، تأیید کنید که رهبر جدیدی از میان پیروان انتخاب شده است. توجه داشته باشید که رهبر می‌توانست در مرکز داده‌ای متفاوت از رهبر فعلی انتخاب شود.

رهبر ارتقا

همان مراحلی را که در ارتقاء Zookeeper در گره‌های ناظر و پیرو در بالا ذکر شد، دنبال کنید.

پس از ارتقاء گره رهبر قدیمی، سلامت خوشه را تأیید کنید و مطمئن شوید که یک گره رهبر وجود دارد.

ارتقاء Nginx 1.26 در Edge-Router

ارتقاء به Edge برای Private Cloud 4.53.01 از نسخه‌های قبلی، نرم‌افزار Nginx را به طور خودکار به آخرین نسخه (1.26.x) ارتقا نمی‌دهد. این کار برای جلوگیری از هرگونه عوارض جانبی تصادفی در زمان اجرا در نتیجه تغییرات مستند شده در Nginx 1.26 در Apigee Edge 4.53.01 است. می‌توانید Nginx را پس از تأیید در محیط‌های پایین‌تر، به صورت دستی از 1.20.x به 1.26.x ارتقا دهید. برای ارتقاء دستی:

1. مطمئن شوید که گره روتر لبه‌ای آخرین نسخه نرم‌افزار ۴.۵۳.۰۱ را دارد.

   /opt/apigee/apigee-service/bin/apigee-service edge-router version

2. نسخه Nginx که در حال حاضر در حال اجرا دارید را بررسی و تأیید کنید

   /opt/nginx/sbin/nginx -V

   اگر از نسخه قدیمی‌تر Nginx استفاده می‌کنید، می‌توانید مراحل زیر را برای ارتقاء Nginx به نسخه 1.26.X در گره روتر دنبال کنید.

3. فرآیند روتر لبه را روی گره روتر متوقف کنید

   /opt/apigee/apigee-service/bin/apigee-service edge-router stop

4. نرم‌افزار nginx را روی گره روتر ارتقا دهید

   dnf update apigee-nginx

5. تأیید کنید که نسخه Nginx به‌روزرسانی شده است

   /opt/nginx/sbin/nginx -V

6. شروع فرآیند روتر روی گره

   /opt/apigee/apigee-service/bin/apigee-service edge-router start

7. این فرآیند را روی هر گره روتر، یکی یکی تکرار کنید.

ارتقاء الزامی به پستگرس ۱۷

این نسخه از اج شامل ارتقاء به Postgres 17 است. به عنوان بخشی از این ارتقاء، تمام داده‌های Postgres به Postgres 17 منتقل می‌شوند.

اکثر سیستم‌های تولید Edge از دو گره Postgres که برای تکثیر master-standby پیکربندی شده‌اند، استفاده می‌کنند. در طول فرآیند به‌روزرسانی، در حالی که گره‌های Postgres برای به‌روزرسانی از کار افتاده‌اند، داده‌های تحلیلی همچنان در گره‌های Qpid نوشته می‌شوند. پس از به‌روزرسانی و آنلاین شدن مجدد گره‌های Postgres، داده‌های تحلیلی به گره‌های Postgres ارسال می‌شوند.

نحوه انجام به‌روزرسانی Postgres به نحوه پیکربندی ذخیره‌سازی داده‌ها برای گره‌های Postgres شما بستگی دارد:

• اگر از فضای ذخیره‌سازی محلی برای گره‌های Postgres خود استفاده می‌کنید ، باید یک گره آماده به کار Postgres جدید را برای مدت زمان ارتقا نصب کنید. پس از اتمام ارتقا، می‌توانید گره آماده به کار Postgres جدید را از کار بیندازید.

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

  در پیکربندی ۱ گره و ۲ گره Edge، توپولوژی‌هایی که برای نمونه‌سازی اولیه و آزمایش استفاده می‌شوند، شما فقط یک گره Postgres دارید. می‌توانید این گره‌های Postgres را مستقیماً و بدون نیاز به ایجاد یک گره Postgres جدید به‌روزرسانی کنید.

• اگر طبق توصیه Apigee از فضای ذخیره‌سازی شبکه برای گره‌های Postgres خود استفاده می‌کنید ، نیازی به نصب یک گره Postgres جدید ندارید. در رویه‌های زیر، می‌توانید از مراحلی که نصب و غیرفعال کردن بعدی یک گره آماده به کار Postgres جدید را مشخص می‌کنند، صرف نظر کنید.

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

نصب یک گره آماده به کار جدید Postgres

این رویه یک سرور آماده به کار Postgres را روی یک گره جدید ایجاد می‌کند. مطمئن شوید که یک سرور آماده به کار Postgres جدید را برای نسخه فعلی Edge خود (4.52.02 یا 4.53.00) نصب می‌کنید، نه برای نسخه 4.53.01.

برای انجام نصب، از همان فایل پیکربندی که برای نصب نسخه فعلی Edge خود استفاده کرده‌اید، استفاده کنید.

برای ایجاد یک گره آماده به کار جدید Postgres:

1. در سرور اصلی فعلی Postgres، فایل /opt/apigee/customer/application/postgresql.properties را ویرایش کنید تا توکن زیر تنظیم شود. اگر این فایل وجود ندارد، آن را ایجاد کنید:

   conf_pg_hba_replication.connection=host replication apigee existing_standby_ip/32 trust\ \nhost replication apigee new_standby_ip/32 trust

   که در آن existing_standby_ip آدرس IP سرور آماده به کار فعلی Postgres و new_standby_ip آدرس IP گره آماده به کار جدید است.

2. apigee-postgresql روی Postgres master مجدداً راه‌اندازی کنید:

   /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

3. با مشاهده فایل /opt/apigee/apigee-postgresql/conf/pg_hba.conf در سرور اصلی، تأیید کنید که گره آماده به کار جدید اضافه شده است. باید خطوط زیر را در آن فایل مشاهده کنید:

   host replication apigee existing_standby_ip/32 trust
   host replication apigee new_standby_ip/32 trust

4. سرور آماده به کار جدید Postgres را نصب کنید:
   1. فایل پیکربندی که برای نصب نسخه فعلی Edge خود استفاده کرده‌اید را ویرایش کنید تا موارد زیر را مشخص کنید:

      # IP address of the current master:
      PG_MASTER=192.168.56.103
      # IP address of the new standby node
      PG_STANDBY=192.168.56.102

   2. SELinux را همانطور که در نصب ابزار Edge apigee-setup توضیح داده شده است، غیرفعال کنید.

   3. اگر در حال حاضر از Edge 4.52.02 استفاده می‌کنید:

      1. فایل Edge bootstrap_4.52.02.sh را در /tmp/bootstrap_4.52.02.sh دانلود کنید:

         curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.51.00.sh

      2. ابزار Edge apigee-service و وابستگی‌های آن را نصب کنید:

         sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord

      اگر در حال حاضر از Edge 4.53.00 استفاده می‌کنید:

      1. فایل Edge bootstrap_4.53.00.sh را در /tmp/bootstrap_4.53.00.sh دانلود کنید:

         curl https://software.apigee.com/bootstrap_4.53.00.sh -o /tmp/bootstrap_4.53.00.sh

      2. ابزار Edge apigee-service و وابستگی‌های آن را نصب کنید:

         sudo bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord

   4. برای نصب ابزار apigee-setup از apigee-service استفاده کنید:

      /opt/apigee/apigee-service/bin/apigee-service apigee-setup install

   5. نصب پستگرس:

      /opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile

   6. در گره آماده به کار جدید، دستور زیر را اجرا کنید:

      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby

      تأیید کنید که حالت آماده به کار است.

انجام ارتقاء داخلی Postgres

مرحله مقدماتی

قبل از انجام ارتقاء درجا به Postgres، مراحل زیر را هم روی میزبان اصلی و هم روی میزبان آماده به کار انجام دهید تا ویژگی max_locks_per_transaction را در apigee-postgresql به‌روزرسانی کنید:

1. اگر وجود ندارد، فایل /opt/apigee/customer/application/postgresql.properties را ایجاد کنید.
2. مالکیت این فایل را به apigee تغییر دهید:

   sudo chown apigee:apigee /opt/apigee/customer/application/postgresql.properties

3. ویژگی زیر را به فایل اضافه کنید:

   conf/postgresql.conf+max_locks_per_transaction=30000

4. پیکربندی apigee-postgresql :

   apigee-service apigee-postgresql configure

5. apigee-postgresql را مجدداً راه‌اندازی کنید:

   apigee-service apigee-postgresql restart

ارتقاء درجا را انجام دهید

برای انجام ارتقاء درجا به Postgres 17، مراحل زیر را انجام دهید:

1. ارتقا postgres روی هاست اصلی

   /opt/apigee/apigee-setup/bin/update.sh -c ps -f /opt/silent.conf

2. دستور setup را روی هاست اصلی اجرا کنید:

   apigee-service apigee-postgresql setup -f /opt/silent.conf

3. دستور configure را روی هاست اصلی اجرا کنید:

   apigee-service apigee-postgresql configure

4. میزبان اصلی را مجدداً راه‌اندازی کنید:

   apigee-service apigee-postgresql restart

5. آن را به عنوان استاد پیکربندی کنید:

   apigee-service apigee-postgresql setup-replication-on-master -f /opt/silent.conf

6. مطمئن شوید که میزبان اصلی شروع به کار کرده است:

   apigee-service apigee-postgresql wait_for_ready

7. حالت آماده به کار را متوقف کنید:

   apigee-service apigee-postgresql stop

8. حالت آماده به کار را ارتقا دهید.

   توجه: اگر این مرحله با خطا/ناموفق مواجه شود، می‌توان آن را نادیده گرفت. update.sh سعی می‌کند سرور آماده به کار را با پیکربندی نادرست راه‌اندازی کند. در صورتی که نصب Postgres به نسخه ۱۷ ارتقا داده شده باشد، می‌توان از این خطا چشم‌پوشی کرد.

   /opt/apigee/apigee-setup/bin/update.sh -c ps -f /opt/silent.conf

9. مطمئن شوید که حالت آماده به کار (standby) متوقف شده است:

   apigee-service apigee-postgresql stop

10. پیکربندی قدیمی حالت آماده به کار را حذف کنید:

    rm -rf /opt/apigee/data/apigee-postgresql/

11. تنظیم تکثیر روی سرور آماده به کار:

    apigee-service apigee-postgresql setup-replication-on-standby -f /opt/silent.conf

12. Remove the line conf/postgresql.conf+max_locks_per_transaction=30000 from the file /opt/apigee/customer/application/postgresql.properties on both the master host and standby. This line was added in the preliminary step .

After completing this procedure, the standby will start successfully.

Decommissioning a Postgres node

After the update completes, decommission the new standby node:

1. Make sure Postgres is running:

   /opt/apigee/apigee-service/bin/apigee-all status

   If Postgres is not running, start it:

   /opt/apigee/apigee-service/bin/apigee-all start

2. Get the UUID of the new standby node by running the following curl command on the new standby node:

   curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self

   You should see the UUID of the node at the end of the output, in the form:

   "type" : [ "postgres-server" ],
   "uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"

3. Stop the new standby node by running the following command on the new standby node:

   /opt/apigee/apigee-service/bin/apigee-all stop

4. On the Postgres master node, edit /opt/apigee/customer/application/postgresql.properties to remove the new standby node from conf_pg_hba_replication.connection :

   conf_pg_hba_replication.connection=host replication apigee existing_standby_ip/32 trust

5. Restart apigee-postgresql on the Postgres master:

   /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

6. Verify that the new standby node was removed by viewing the /opt/apigee/apigee-postgresql/conf/pg_hba.conf file on the master. You should see only the following line in that file:

   host replication apigee existing_standby_ip/32 trust

7. Delete the UUID of the standby node from ZooKeeper by making the following Edge management API call on the Management Server node:

   curl -u sysAdminEmail:password -X DELETE http://ms_IP:8080/v1/servers/new_standby_uuid

Post-upgrade steps for Postgres

After a major Postgres upgrade, the internal statistics of Postgres are wiped out. These statistics aid the Postgres query planner in utilizing the most optimal indexes and paths to execute queries.

Postgres can gradually rebuild its statistics over time as queries are executed and when the autovacuum daemon runs. However, until the statistics are rebuilt, your queries may be slow.

To address this issue, execute ANALYZE on all tables in the database on the master Postgres node. Alternatively, you can execute ANALYZE for a few tables at a time.

Steps for updating Apigee SSO from older versions

In Edge for Private Cloud 4.53.01, the IDP keys and certificates used in the apigee-sso component are now configured through a keystore. You will need to export the key and certificate used earlier into a keystore, configure it, and then proceed with the SSO update as usual.

1. Identify the existing key and certificate used for configuring IDP:

   1. Retrieve the certificate by looking up the value of SSO_SAML_SERVICE_PROVIDER_CERTIFICATE in the SSO installation configuration file or by querying the apigee-sso component for conf_login_service_provider_certificate .

      Use the following command on the SSO node to query apigee-sso for the IDP certificate path. In the output, look for the value in the last line.

      apigee-service apigee-sso configure -search conf_login_service_provider_certificate

   2. Retrieve the key by looking up the value of SSO_SAML_SERVICE_PROVIDER_KEY in the SSO installation configuration file or by querying the apigee-sso component for conf_login_service_provider_key .

      Use the following command on the SSO node to query apigee-sso for the IDP key path. In the output, look for the value on the last line.

      apigee-service apigee-sso configure -search conf_login_service_provider_key

2. Export the key and certificate to a keystore:
   1. Export the key and certificate to a PKCS12 keystore:

      sudo openssl pkcs12 -export -clcerts -in <certificate_path> -inkey <key_path> -out <keystore_path> -name <alias>

      Parameters:

      • certificate_path : Path to the certificate file retrieved in Step 1.a.
      • key_path : Path to the private key file retrieved in Step 1.b.
      • keystore_path : Path to the newly created keystore containing the certificate and private key.
      • alias : Alias used for the key and certificate pair within the keystore.

      Refer to the OpenSSL documentation for more details.

   2. (Optional) Export the key and certificate from PKCS12 to a JKS keystore:

      sudo keytool -importkeystore -srckeystore <PKCS12_keystore_path> -srcstoretype PKCS12 -destkeystore <destination_keystore_path> -deststoretype JKS -alias <alias>

      Parameters:

      • PKCS12_keystore_path : Path to the PKCS12 keystore created in Step 2.a, containing the certificate and key.
      • destination_keystore_path : Path to the new JKS keystore where the certificate and key will be exported.
      • alias : Alias used for the key and certificate pair within the JKS keystore.

   Refer to the keytool documentation for more details.

3. Change the owner of the output keystore file to the "apigee" user:

   sudo chown apigee:apigee <keystore_file>

4. Add the following properties in Apigee SSO configuration file and update them with the keystore file path, password, keystore type, and alias:

   # Path to the keystore file
   SSO_SAML_SERVICE_PROVIDER_KEYSTORE_PATH=${APIGEE_ROOT}/apigee-sso/source/conf/keystore.jks
   
   # Keystore password
   SSO_SAML_SERVICE_PROVIDER_KEYSTORE_PASSWORD=Secret123  # Password for accessing the keystore
   
   # Keystore type
   SSO_SAML_SERVICE_PROVIDER_KEYSTORE_TYPE=JKS  # Type of keystore, e.g., JKS, PKCS12
   
   # Alias within keystore that stores the key and certificate
   SSO_SAML_SERVICE_PROVIDER_KEYSTORE_ALIAS=service-provider-cert 

5. Update Apigee SSO software on the SSO node as usual using the following command:

   /opt/apigee/apigee-setup/bin/update.sh -c sso -f /opt/silent.conf

New Edge UI

This section lists considerations regarding the Edge UI. For more information, see The new Edge UI for Private Cloud .

Install the Edge UI

After you complete the initial installation, Apigee recommends that you install the Edge UI, which is an enhanced user interface for developers and administrators of Apigee Edge for Private Cloud.

Note that the Edge UI requires that you disable Basic authentication and use an IDP such as SAML or LDAP.

For more information, see Install the new Edge UI .

Update with Apigee mTLS

To update Apigee mTLS , do the following steps:

• Uninstall Apigee mTLS .
• Re-install Apigee mTLS .

Rolling back an update

In the case of an update failure, you can try to correct the issue, and then execute update.sh again. You can run the update multiple times and it continues the update from where it last left off.

If the failure requires that you roll back the update to your previous version, see Roll back 4.53.01 for detailed instructions.

Logging update information

By default, the update.sh utility writes log information to:

/opt/apigee/var/log/apigee-setup/update.log

If the person running the update.sh utility does not have access to that directory, it writes the log to the /tmp directory as a file named update_username.log .

If the person does not have access to /tmp , the update.sh utility fails.

Zero-downtime update

A zero-downtime update, or rolling update, lets you update your Edge installation without bringing down Edge.

Zero-downtime update is only possible with a 5-node configuration and larger.

The key to zero-downtime upgrading is to remove each Router, one at a time, from the load balancer. You then update the Router and any other components on the same machine as the Router, and then add the Router back to the load balancer.

1. Update the machines in the correct order for your installation as described Order of machine update .
2. When it is time to update the Routers, select any one Router and make it unreachable, as described in Enabling/Disabling server (Message Processor/Router) reachability .
3. Update the selected Router and all other Edge components on the same machine as the Router. All Edge configurations show a Router and Message Processor on the same node.
4. Make the Router reachable again.
5. Repeat steps 2 through 4 for the remaining Routers.
6. Continue the update for any remaining machines in your installation.

Take care of the following before and after the update:

• On combined Router and Message Processor node:
  • Before update – perform the following:
    1. Make the Router unreachable.
    2. Make the Message Processor unreachable.
  • After update – perform the following:
    1. Make the Message Processor reachable.
    2. Make the Router reachable.
• On single Router nodes:
  • Before update, make the Router unreachable .
  • After update, make the Router reachable .
• On single Message Processor nodes:
  • Before update, make the Message Processor unreachable .
  • After update, make the Message Processor reachable .

Use a silent configuration file

You must pass a silent configuration file to the update command. The silent configuration file should be the same one that you used to install Edge for Private Cloud 4.52.02 or 4.53.00.

Update to 4.53.01 on a node with an external internet connection

Use the following procedure to update the Edge components on a node:

1. If present, disable any cron jobs configured to perform a repair operation on Cassandra until after the update completes.
2. Log in to your node as root to install the Edge RPMs.
3. Disable SELinux as described in Install the Edge apigee-setup utility .
4. If you are installing on AWS , execute the following yum-configure-manager commands:

   yum update rh-amazon-rhui-client.noarch
   sudo yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

5. If you are currently on Edge 4.52.02 or 4.53.00:

   1. Download the Edge bootstrap_4.53.01.sh file to /tmp/bootstrap_4.53.01.sh :

      curl https://software.apigee.com/bootstrap_4.53.01.sh -o /tmp/bootstrap_4.53.01.sh

   2. Install the Edge 4.53.01 apigee-service utility and dependencies by executing the following command:

      sudo bash /tmp/bootstrap_4.53.01.sh apigeeuser=uName apigeepassword=pWord

      Where uName:pWord are the username and password you received from Apigee. If you omit pWord , you will be prompted to enter it.

      By default, the installer checks that you have Java 1.8 installed. If you do not, the installer installs it for you.

      Use the JAVA_FIX option to specify how to handle Java installation. JAVA_FIX takes the following values:

      • I : Install OpenJDK 1.8 (default).
      • C : Continue without installing Java.
      • Q : Quit. For this option, you must install Java yourself.
   3. Use apigee-service to update the apigee-setup utility, as the following example shows:

      /opt/apigee/apigee-service/bin/apigee-service apigee-setup update

   4. Update the apigee-validate utility on the Management Server, as the following example shows:

      /opt/apigee/apigee-service/bin/apigee-service apigee-validate update

   5. Update the apigee-provision utility on the Management Server, as the following example shows:

      /opt/apigee/apigee-service/bin/apigee-service apigee-provision update

   6. Run the update utility on your nodes by executing the following command:

      /opt/apigee/apigee-setup/bin/update.sh -c component -f configFile

      Do this in the order described in Order of machine update .

      Where:

      • component is the Edge component to update. Possible values include:
        • cs : Cassandra
        • edge : All Edge components except Edge UI: Management Server, Message Processor, Router, QPID Server, Postgres Server
        • ldap : OpenLDAP
        • ps : postgresql
        • qpid : qpidd
        • sso : Apigee SSO (if you installed SSO)
        • ue : New Edge UI
        • ui : Classic Edge UI
        • zk : Zookeeper
      • configFile is the same configuration file that you used to define your Edge components during the 4.52.02 or 4.53.00 installation.

      You can run update.sh against all components by setting component to "all", but only if you have an Edge all-in-one (AIO) installation profile. For example:

      /opt/apigee/apigee-setup/bin/update.sh -c all -f ./sa_silent_config

   7. Restart the Edge UI components on all nodes running them, if you haven't done so already:

      /opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart

   8. Test the update by running the apigee-validate utility on the Management Server, as described in Test the install .

If you later decide to roll back the update, use the procedure described in Roll back 4.53.01 .

Update to 4.53.01 from a local repo

If your Edge nodes are behind a firewall, or in some other way are prohibited from accessing the Apigee repository over the Internet, then you can perform the update from a local repository, or mirror, of the Apigee repo.

After you create a local Edge repository, you have two options for updating Edge from the local repo:

• Create a .tar file of the repo, copy the .tar file to a node, and then update Edge from the .tar file.
• Install a webserver on the node with the local repo so that other nodes can access it. Apigee provides the Nginx webserver for you to use, or you can use your own webserver.

To update from a local 4.53.01 repo:

1. Create a local 4.53.01 repo as described in "Create a local Apigee repository" at Install the Edge apigee-setup utility .
2. To install apigee-service from a .tar file :
   1. On the node with the local repo, use the following command to package the local repo into a single .tar file named /opt/apigee/data/apigee-mirror/apigee-4.53.01.tar.gz :

      /opt/apigee/apigee-service/bin/apigee-service apigee-mirror package

   2. Copy the .tar file to the node where you want to update Edge. For example, copy it to the /tmp directory on the new node.
   3. On the new node, untar the file to the /tmp directory:

      tar -xzf apigee-4.53.01.tar.gz

      This command creates a new directory, named repos , in the directory containing the .tar file. For example /tmp/repos .

   4. Install the Edge apigee-service utility and dependencies from /tmp/repos :

      sudo bash /tmp/repos/bootstrap_4.53.01.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos

      Notice that you include the path to the repos directory in this command.

3. To install apigee-service using the Nginx webserver:
   1. Configure the Nginx web server as described in "Install from the repo using the Nginx webserver" at Install the Edge apigee-setup utility .
   2. On the remote node, download the Edge bootstrap_4.53.01.sh file to /tmp/bootstrap_4.53.01.sh :

      /usr/bin/curl http://uName:pWord@remoteRepo:3939/bootstrap_4.53.01.sh -o /tmp/bootstrap_4.53.01.sh

      Where uName:pWord are the username and password you set previously for the repo, and remoteRepo is the IP address or DNS name of the repo node.

   3. On the remote node, install the Edge apigee-setup utility and dependencies:

      sudo bash /tmp/bootstrap_4.53.01.sh apigeerepohost=remoteRepo:3939 apigeeuser=uName apigeepassword=pWord apigeeprotocol=http://

      Where uName:pWord are the repo username and password.

4. Use apigee-service to update the apigee-setup utility, as the following example shows:

   /opt/apigee/apigee-service/bin/apigee-service apigee-setup update 

5. Update the apigee-validate utility on the Management Server, as the following example shows:

   /opt/apigee/apigee-service/bin/apigee-service apigee-validate update

6. Update the apigee-provision utility on the Management Server, as the following example shows:

   /opt/apigee/apigee-service/bin/apigee-service apigee-provision update

7. Run the update utility on your nodes in the order described in Order of machine update :

   /opt/apigee/apigee-setup/bin/update.sh -c component -f configFile

   Where:

   • component is the Edge component to update. You typically update the following components:
     • cs : Cassandra
     • edge : All Edge components except Edge UI: Management Server, Message Processor, Router, QPID Server, Postgres Server
     • ldap : OpenLDAP
     • ps : postgresql
     • qpid : qpidd
     • sso : Apigee SSO (if you installed SSO)
     • ue New Edge UI
     • ui : Classic Edge UI
     • zk : Zookeeper
   • configFile is the same configuration file that you used to define your Edge components during the 4.52.02 or 4.53.00 installation.

   You can run update.sh against all components by setting component to "all", but only if you have an Edge all-in-one (AIO) installation profile. For example:

   /opt/apigee/apigee-setup/bin/update.sh -c all -f /tmp/sa_silent_config

8. Restart the UI components on all nodes running it, if you haven't done so already:

   /opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart

9. Test the update by running the apigee-validate utility on the Management Server, as described in Test the install .

If you later decide to roll back the update, use the procedure described in Roll back 4.53.01 .

Order of machine update

The order that you update the machines in an Edge installation is important:

• You must update all LDAP nodes before updating any other components. You will need to follow special steps to upgrade LDAP.
• You must update all Cassandra and ZooKeeper nodes. If you're upgrading from 4.52.02 then, follow the special steps to upgrade cassandra. You will need to follow the special steps to upgrade Zookeeper for 4.52.02 or 4.53.00.
• You must upgrade all the Management Servers and Router & Message Processors using the -c edge option to update them.
• You must upgrade all Postgres nodes following the special steps for upgrade Postgres.
• You must update edge-qpid-server & edge-postgres-server components across all data centers.
• You must upgrade all Qpid nodes.
• You must upgrade Edge UI nodes and also upgrade the New Edge UI and SSO nodes(if applicable).
• There is no separate step to update Monetization. It is updated when you specify the -c edge option.

1-node standalone upgrade

To upgrade a 1-node standalone configuration to 4.53.01:

1. Update all components:

   /opt/apigee/apigee-setup/bin/update.sh -c all -f configFile

2. (If you installed apigee-adminapi ) Update the apigee-adminapi utility:

   /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

2-node standalone upgrade

Update the following components for a 2-node standalone installation:

See Installation topologies for the list of Edge topologies and node numbers.

1. Update LDAP on machine 1:

   /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

2. Update Cassandra and ZooKeeper on machine 1:

   /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile

3. Update Edge components on machine 1:

   /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

4. Update Postgres on machine 2:

   /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

5. Update Edge components on machine 1:

   /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

6. Update Qpid on Machine 2:

   /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

7. Update the UI on machine 1:

   /opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile

8. (If you installed apigee-adminapi ) Updated the apigee-adminapi utility on machine 1:

   /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

9. (If you installed Apigee SSO) Update Apigee SSO on machine 1:

   /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

   Where sso_config_file is the configuration file you created when you installed SSO .

10. Restart the Edge UI component on machine 1:

    /opt/apigee/apigee-service/bin/apigee-service edge-ui restart

5-node upgrade

Update the following components for a 5-node installation:

See Installation topologies for the list of Edge topologies and node numbers.

1. Update LDAP on machine 1:

   /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

2. Update Cassandra and ZooKeeper on machine 1, 2, and 3:

   /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile

3. Update Edge components on machine 1, 2, 3:

   /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

4. Update Postgres on machine 4:

   /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

5. Update Postgres on machine 5:

   /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

6. Update Edge components on machine 4, 5:

   /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

7. Update Qpid on machine 4:

   /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

8. Update Qpid on machine 5:

   /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

9. Update the Edge UI:
   • Classic UI: If you are using the classic UI, then update the ui component on machine 1, as the following example shows:

     /opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile

   • New Edge UI: If you installed the new Edge UI, then update the ue component on the appropriate machine (may not be machine 1):

     /opt/apigee/apigee-setup/bin/update.sh -c ue -f /opt/silent.conf

10. (If you installed apigee-adminapi ) Updated the apigee-adminapi utility on machine 1:

    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

11. (If you installed Apigee SSO) Update Apigee SSO on machine 1:

    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    Where sso_config_file is the configuration file you created when you installed SSO .

12. Restart the UI component:
    • Classic UI: If you are using the classic UI, then restart the edge-ui component on machine 1, as the following example shows:

      /opt/apigee/apigee-service/bin/apigee-service edge-ui restart

    • New Edge UI: If you installed the new Edge UI, then restart the edge-management-ui component on the appropriate machine (may not be machine 1):

      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart

9-node clustered upgrade

Update the following components for a 9-node clustered installation:

See Installation topologies for the list of Edge topologies and node numbers.

1. Update LDAP on machine 1:

   /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

2. Update Cassandra and ZooKeeper on machine 1, 2, and 3:

   /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile

3. Update Edge components on machine 1, 4, and 5 (Management server, message processor, router) in that order:

   /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

4. Update Postgres on machine 8:

   /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

5. Update Postgres on machine 9:

   /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

6. Update Edge components on machine 6, 7, 8, and 9 in that order:

   /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

7. Update Qpid on machines 6 and 7:

   /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

8. Update either the new UI ( ue ) or classic UI ( ui ) on machine 1:

   /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile

9. (If you installed apigee-adminapi ) Update the apigee-adminapi utility on machine 1:

   /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

10. (If you installed Apigee SSO) Update Apigee SSO on machine 1:

    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    Where sso_config_file is the configuration file you created when you installed SSO .

11. Restart the UI component:
    • Classic UI: If you are using the classic UI, then restart the edge-ui component on machine 1, as the following example shows:

      /opt/apigee/apigee-service/bin/apigee-service edge-ui restart

    • New Edge UI: If you installed the new Edge UI, then restart the edge-management-ui component on the appropriate machine (may not be machine 1):

      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart

13-node clustered upgrade

Update the following components for a 13-node clustered installation:

See Installation topologies for the list of Edge topologies and node numbers.

1. Update LDAP on machine 4 and 5:

   /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

2. Update Cassandra and ZooKeeper on machines 1, 2, and 3:

   /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile

3. Update Edge components on machines 6, 7, 10, and 11 in that order:

   /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

4. Update Postgres on machine 8:

   /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

5. Update Postgres on machine 9:

   /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

6. Update Edge components on machines 12, 13, 8, and 9 in that order:

   /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

7. Update Qpid on machines 12 and 13:

   /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

8. Update either the new UI ( ue ) or classic UI ( ui ) on machines 6 and 7:

   /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile

9. (If you installed apigee-adminapi ) Updated the apigee-adminapi utility on machines 6 and 7:

   /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

10. (If you installed Apigee SSO) Update Apigee SSO on machines 6 and 7:

    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    Where sso_config_file is the configuration file you created when you installed SSO .

11. Restart the UI component:
    • Classic UI: If you are using the classic UI, then restart the edge-ui component on machines 6 and 7, as the following example shows:

      /opt/apigee/apigee-service/bin/apigee-service edge-ui restart

    • New Edge UI: If you installed the new Edge UI, then restart the edge-management-ui component on machines 6 and 7:

      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart

12-node clustered upgrade

Update the following components for a 12-node clustered installation:

See Installation topologies for the list of Edge topologies and node numbers.

1. Update LDAP:
   1. Machine 1 in Data Center 1

      /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

   2. Machine 7 in Data Center 2

      /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

2. Update Cassandra and ZooKeeper:
   1. Machines 1, 2 and 3 in Data center 1:

      /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile

   2. On machines 7, 8, and 9 in Data Center 2:

      /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile

3. Update Edge components:
   1. On machines 1, 2 and 3 in Data Center 1:

      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

   2. On machines 7, 8, and 9 in Data Center 2

      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

4. Update Postgres:
   1. Machine 6 in Data Center 1

      /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

   2. Machine 12 in Data Center 2

      /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

5. Update Edge components:
   1. Machines 4, 5, 6 in Data Center 1

      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

   2. Machines 10, 11, 12 in Data Center 2

      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

6. Update qpidd:
   1. Machines 4, 5 in Data Center 1
      1. Update qpidd on machine 4:

         /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

      2. Update qpidd on machine 5:

         /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

   2. Machines 10, 11 in Data Center 2
      1. Update qpidd on machine 10:

         /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

      2. Update qpidd on machine 11:

         /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

7. Update either the new UI ( ue ) or classic UI ( ui ):
   1. Machine 1 in Data Center 1:

      /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile

   2. Machine 7 in Data Center 2:

      /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile

8. (If you installed apigee-adminapi ) Updated the apigee-adminapi utility:
   1. Machine 1 in Data Center 1:

      /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

   2. Machine 7 in Data Center 2:

      /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

9. (If you installed Apigee SSO) Update Apigee SSO:
   1. Machine 1 in Data Center 1:

      /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

   2. Machine 7 in Data Center 2:

      /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

   Where sso_config_file is the configuration file you created when you installed SSO .

10. Restart the new Edge UI ( edge-management-ui ) or classic Edge UI ( edge-ui ) component on machines 1 and 7:

    /opt/apigee/apigee-service/bin/apigee-service [edge-ui|edge-management-ui] restart

For a non-standard configuration

If you have a non-standard configuration, then update Edge components in the following order:

1. LDAP
2. کاساندرا
3. Zookeeper
4. Management Server
5. Message Processor
6. روتر
7. پستگرس
8. Edge, meaning the "-c edge" profile on all nodes in the order: nodes with Qpid server, Edge Postgres Server.
9. qpidd
10. Edge UI (either classic or new)
11. apigee-adminapi
12. Apigee SSO

After you finish updating, be sure to restart the Edge UI component on all machines running it.