این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

به روز رسانی Apigee Edge 4.51.00 یا 4.52.00 یا 4.52.01 به 4.52.02

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

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

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

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

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

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

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

قبل از ارتقاء Apigee Edge، پیش‌نیازهای زیر را بررسی کنید:

پشتیبان گیری از تمام گره ها
قبل از به‌روزرسانی، به دلایل ایمنی توصیه می‌کنیم که از تمام گره‌ها یک نسخه پشتیبان کامل تهیه کنید. برای انجام پشتیبان‌گیری از رویه مربوط به نسخه فعلی Edge خود استفاده کنید.
این به شما امکان می‌دهد در صورتی که به‌روزرسانی به نسخه جدید به درستی کار نکند، یک برنامه پشتیبان داشته باشید. برای اطلاعات بیشتر در مورد پشتیبان‌گیری، به بخش پشتیبان‌گیری و بازیابی مراجعه کنید.
مطمئن شوید که Edge در حال اجرا است
با استفاده از دستور زیر، مطمئن شوید که Edge در طول فرآیند به‌روزرسانی فعال و در حال اجرا است:
```
/opt/apigee/apigee-service/bin/apigee-all status
```
توجه: اطمینان حاصل کنید که تنظیمات سرور مدیریت لبه (edge-management-server) در نسخه فعلی شما با موفقیت و بدون مشکل اجرا می‌شود. قبل از ادامه ارتقاء، هرگونه مشکل در تنظیمات سرور مدیریت لبه (edge-management-server) از نسخه‌های قبلی را برطرف کنید.
اطمینان حاصل کنید که استراتژی فشرده‌سازی کاساندرا (Cassandra Compaction Strategy) به LeveledCompactionStrategy است.
بسته به نسخه فعلی خود، تغییرات لازم را در استراتژی فشرده‌سازی کاساندرا انجام دهید. مراحل زیر را دنبال کنید و سپس به رویه اصلی ارتقا برگردید:
- اگر از نسخه ۴.۵۱.۰۰ ارتقا می‌دهید، برای نسخه ۴.۵۱.۰۰ به سند استراتژی فشرده‌سازی کاساندرا مراجعه کنید.
- اگر از نسخه ۴.۵۲.۰۰ ارتقا می‌دهید، برای نسخه ۴.۵۲.۰۰ به سند استراتژی فشرده‌سازی کاساندرا مراجعه کنید.
- اگر از نسخه ۴.۵۲.۰۱ ارتقا می‌دهید، برای نسخه ۴.۵۲.۰۱ به سند استراتژی فشرده‌سازی کاساندرا مراجعه کنید.

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

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

نسخه فعلی	نرم‌افزاری که برای ارتقا به نسخه ۴.۵۲.۰۲ به مراحل خاصی نیاز دارد
۴.۵۲.۰۱	کاساندرا
۴.۵۲.۰۰	نگهبان باغ وحش ، کاساندرا ، کیوپید
۴.۵۱.۰۰	زوکیپر ، پستگرس ، کاساندرا ، کیوپید

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

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

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

ارتقا به زوکیپر ۳.۸.۳

نسخه ۴.۵۲.۰۲ مرورگر اج برای فضای ابری خصوصی شامل ارتقاء به زوکیپر نمی‌شود. با این حال، اگر از نسخه‌ای قدیمی‌تر از ۴.۵۲.۰۱ به نسخه جدیدتر ارتقا می‌دهید، لازم است مراحل ارتقاء زوکیپر که در زیر ذکر شده است را دنبال کنید.

اگر در حال ارتقا از نسخه‌های ۴.۵۱.۰۰ یا ۴.۵۲.۰۰ اج برای فضای ابری خصوصی هستید، برای ارتقای زوکیپر به مراحل موجود در «ارتقای الزامی به زوکیپر ۳.۸.۳» مراجعه کنید.
اگر در حال ارتقا از نسخه ۴.۵۲.۰۱ مرورگر اج برای فضای ابری خصوصی هستید، باید از قبل از نسخه ۳.۸.۳ زوکیپر استفاده کنید و نیازی به دنبال کردن مراحل خاصی برای ارتقای زوکیپر ندارید.

توجه:

ارتقا از Edge for Private Cloud 4.52.01 به 4.52.02 ساده شده است زیرا Zookeeper و Cassandra معمولاً در یک میزبان یا ماشین مجازی قرار دارند که این امر لزوم انجام مراحل جداگانه ارتقای Zookeeper را در کنار ارتقای قابل توجه Cassandra از بین می‌برد.

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

دستور زیر ارتقاء جداگانه‌ی Zookeeper را تسهیل می‌کند:

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

برای بازگرداندن Zookeeper، از رویه استاندارد بازگرداندن Zookeeper استفاده کنید. اگر بازگرداندن برای Cassandra یا سایر اجزا ضروری شود، آن اجزا باید برگردانده شوند؛ بازگرداندن Zookeeper الزامی نیست.

ارتقا به پستگرس ۱۴

اگر در حال ارتقا از Edge for Private Cloud 4.51.00 به 4.52.02 هستید، باید مراحل ارتقای Postgres را دنبال کنید، حتی اگر Edge for Private Cloud 4.52.02 شامل ارتقای Postgres نباشد. ارتقا از Edge for Private Cloud 4.51.00 به 4.52.02 نیاز به مراحل ارتقای Postgres اضافی دارد. لطفاً به بخش ارتقای الزامی به Postgres 14 مراجعه کنید.
اگر از Edge for Private Cloud نسخه ۴.۵۲.۰۰ یا ۴.۵۲.۰۱ به ۴.۵۲.۰۲ ارتقا می‌دهید، هیچ مرحله اضافی برای ارتقاء Postgres لازم نیست.

توجه:

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

برای بازگرداندن Postgres، از رویه استاندارد بازگرداندن Postgres پیروی کنید. اگر بازگرداندن Cassandra یا سایر اجزا ضروری است، آن اجزا را بازگردانید؛ بازگرداندن Postgres لازم نیست.

ارتقا به کاساندرا ۳.۱۱.۱۶

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

از آنجایی که این یک ارتقاء بزرگ است، تغییرات خاصی در مدل داده Apigee در Cassandra برای تضمین عملکرد بهینه در نسخه‌های جدیدتر ضروری بود. اگرچه این تغییرات جزئی هستند، اما فرآیند ارتقاء، هنگام شروع ارتقاء، APIهای مدیریتی خاصی را مختل می‌کند. APIهای مدیریتی دقیقی که عموماً مختل می‌شوند، در بخش‌های مربوطه در زیر فهرست شده‌اند.

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

توجه: ابزار cassandra-cli دیگر در Cassandra 3.X پشتیبانی نمی‌شود و برای استفاده شما در دسترس نیست.

پورتال توسعه‌دهندگان - مستندسازی APIها

پورتال توسعه‌دهندگان Apigee Drupal ویژگی‌های مختلفی را برای مستندسازی APIهای شما ارائه می‌دهد. اگرچه توصیه می‌شود که استفاده از پورتال توسعه‌دهندگان مبتنی بر Drupal 7 را کنار بگذارید، اما اگر هنوز از آن استفاده می‌کنید و از ویژگی SmartDocs آن بهره می‌برید، سند «استفاده از SmartDocs APIs» برای شما اعمال می‌شود. اگر از نسخه‌های جدیدتر پورتال توسعه‌دهندگان استفاده می‌کنید، این به‌روزرسانی هیچ تأثیری بر مستندات API شما نخواهد داشت.

وقتی Apigee را به نسخه ۴.۵۲.۰۲ ارتقا می‌دهید، هیچ مدل API ایجاد شده با استفاده از ویژگی SmartDocs پورتال توسعه‌دهندگان Drupal 7 به طور خودکار به نسخه جدیدتر منتقل نمی‌شود. از شما انتظار می‌رود که هر مدل را با استفاده از پورتال توسعه‌دهندگان به صورت دستی export کرده و پس از تکمیل ارتقا، دوباره import کنید.

اصطلاحات استفاده شده در زیر

زمان اجرا: زمان اجرا شامل مدیریت ترافیک پروکسی زمان اجرا می‌شود. این شامل تمام عملیاتی است که توسط روترها و پردازنده‌های پیام شما برای پردازش مؤثر درخواست API زمان اجرا برای پروکسی‌های موجود انجام می‌شود. با این حال، شامل استقرار پروکسی‌های جدید یا نسخه‌های جدید پروکسی‌ها نمی‌شود.

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

در طول این ارتقا، ترافیک زمان اجرا و مدیریت در منطقه یا مرکز داده (DC) که به‌روزرسانی در آن اجرا می‌شود، تحت تأثیر قرار می‌گیرد. صرف نظر از مرکز داده‌ای که به‌روزرسانی می‌شود، تأثیری بر APIهای مدیریتی خاصی در تمام مراکز داده وجود دارد. این تأثیر پس از هر مرحله ثبت می‌شود.

در هر مرحله زیر، وضعیت زمان اجرا و مدیریت، همزمان با پیشرفت شما در مراحل مختلف فرآیند ارتقا، شرح داده شده است.

استراتژی‌های ارتقا

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

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

توجه:

برای جلوگیری از تأثیر ترافیک در طول ارتقاء، رویکرد مرکز داده به مرکز داده (DC-by-DC) را دنبال کنید و ترافیک را به طور موقت از مرکز داده‌ای که در حال ارتقاء است، دور کنید. این کار، فرآیند ارتقاء کنترل‌شده‌ای را برای گره‌های Cassandra ، Management Server و Runtime تضمین می‌کند و در عین حال، در دسترس بودن سرویس را حفظ می‌کند.

برای راه‌اندازی دو مرکز داده ، این مراحل سطح بالا را دنبال کنید:

ترافیک را از DC-1 به DC-2 هدایت کنید و ترافیک ورودی به DC-1 را مسدود کنید.
DC-1 ، شامل اجزای Cassandra ، Management Server و Runtime را ارتقا دهید.
ترافیک را به DC-1 هدایت کنید و ترافیک ورودی به DC-2 را مسدود کنید.
DC-2 ، شامل اجزای Cassandra ، Management Server و Runtime را ارتقا دهید.

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

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

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

با اضافه کردن یک مرکز داده در کنار مرکز داده موجود برای مدیریت ترافیک در طول ارتقا، خوشه ابر خصوصی Edge خود را به یک مرکز داده موقت گسترش دهید، سپس پس از اتمام فرآیند ارتقا، یکی از مراکز داده را از رده خارج کنید .
اگر قادر به گسترش به یک مرکز داده اضافی نیستید، برای زمان از کارافتادگی آماده شوید و ارتقاء را در دوره‌های کم ترافیک برنامه‌ریزی کنید تا تأثیر بر APIهای مدیریتی و ترافیک زمان اجرا به حداقل برسد.

توصیه می‌شود برای جلوگیری از تأثیر بر ترافیک زمان اجرا و APIهای مدیریتی، به یک مرکز داده اضافی گسترش یابد. در طول ارتقا، تأثیرات بر مرکز داده در حال ارتقا شامل موارد زیر است، اما محدود به آنها نیست:

APIهای زمان اجرا، توکن‌های OAuth را به‌روزرسانی می‌کنند
API های زمان اجرا با استفاده از Access Entity Policy
APIهای مدیریتی که برنامه‌های توسعه‌دهنده را فهرست می‌کنند
API های مدیریتی فهرست کننده محصولات

تأثیری که در بالا توضیح داده شد، علاوه بر APIهای مدیریتی خاصی است که تا زمان ارتقاء همه مراکز داده، در همه مراکز داده غیرفعال باقی خواهند ماند. چنین APIهای مدیریتی در مراحل بخش‌های بعدی فهرست شده‌اند.

عقبگرد - سطح بالا

تأثیر در طول عقبگرد
بازگشت از کاساندرا ۳.۱۱.x به ۲.۱.x هم بر زمان اجرا و هم بر ترافیک مدیریتی در مرکز داده (DC) که در آن بازگشت انجام می‌شود، تأثیر می‌گذارد. علاوه بر این، APIهای مدیریتی خاص ممکن است در تمام مراکز داده، صرف نظر از اینکه کدام مرکز داده در حال حاضر در حال بازگشت است، دچار اختلال شوند.
رویکرد عقب‌گرد DC را با رویکرد DC دنبال کنید
برای حفظ تداوم سرویس و جلوگیری از خرابی، باید Rollback در هر مرکز داده به صورت جداگانه انجام شود. قبل از شروع Rollback در یک DC خاص، اطمینان حاصل کنید که ترافیک برنامه به یک مرکز داده کاملاً عملیاتی دیگر هدایت می‌شود.
بازگرداندن خوشه‌ی تا حدی ارتقا یافته
اگر حداقل یک مرکز داده با نسخه قدیمی‌تر کاساندرا (۲.۱.۲۲) کاملاً عملیاتی باقی بماند، سایر مراکز داده ارتقا یافته را می‌توان با انجام بازسازی از مرکز داده کاملاً کاربردی کاساندرا ۲.۱.X به حالت اولیه بازگرداند.
بازگرداندن به حالت اولیه در کل کلاستر
اگر کل کلاستر کاساندرا ارتقا یافته باشد و نیاز به بازگرداندن به نسخه قبلی باشد، باید با استفاده از پشتیبان‌گیری یا اسنپ‌شات‌های ماشین مجازی انجام شود. این رویکرد پیچیده است و احتمالاً منجر به از کارافتادگی موقت یا از دست رفتن داده‌ها خواهد شد.
ملاحظات قبل از ارتقا
مهم است که قبل از اقدام به ارتقا، با رویه‌های بازگشت به نسخه قبلی آشنا شوید. بسیار مهم است که هنگام ارتقا، نکات ظریف بازگشت به نسخه قبلی در نظر گرفته شود تا از وجود مسیرهای مناسب برای بازگشت به نسخه قبلی اطمینان حاصل شود.

خوشه‌های عقب‌گرد با یک مرکز داده واحد

ارتقاء کاساندرا از نسخه 2.1.x به 3.11.x می‌تواند به طور قابل توجهی بر ترافیک زمان اجرا و برخی از APIهای مدیریتی تأثیر بگذارد. این تأثیرات همچنین در هنگام بازگشت به نسخه قبلی اعمال می‌شوند و ممکن است منجر به از کار افتادن یا از دست رفتن داده‌ها شوند.

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

اگر اضافه کردن یک مرکز داده جدید امکان‌پذیر نیست اما قابلیت بازگشت به نسخه قبلی همچنان مورد نیاز است، اطمینان حاصل کنید که قبل از ارتقا، پشتیبان‌های قابل اعتمادی تهیه شده است. بازیابی Cassandra 2.1.x از پشتیبان‌ها امکان‌پذیر است، اما این رویکرد ممکن است شامل از کار افتادن سرویس و از دست رفتن احتمالی داده‌ها باشد.

خوشه‌های عقب‌گرد با چندین مرکز داده

بازگرداندن چندین مرکز داده به حالت اولیه، از رویکرد مرکز داده به مرکز داده (DC-by-DC) پیروی می‌کند. در این رویکرد، ترافیک مرکز داده‌ای که قرار است به حالت اولیه برگردد، به سایر مراکز داده کاربردی هدایت می‌شود و یک فرآیند بازگرداندن کنترل‌شده و ایزوله را برای گره‌های Cassandra ، Management Server و Runtime تضمین می‌کند تا از اختلال در ترافیک جلوگیری شود.

برای جزئیات بیشتر به بخش بازگرداندن به‌روزرسانی کاساندرا ۳.۱۱.۱۶ مراجعه کنید.

مرحله ۰: حالت شروع

اجزای Zookeeper، Postgres و LDAP از قبل به نسخه‌های ۴.۵۲.۰۲ ارتقا یافته‌اند. Edge شما برای یک خوشه ابر خصوصی پایدار و در حال کار است. در صورت نیاز به بازگشت به نسخه قبلی، خوشه به این حالت بازگردانده می‌شود.
کاساندرا در Apigee با نسخه ۲.۱.۲۲ اجرا می‌شود.
اجزای لبه:

ارتباط سرور مدیریت با کاساندرا از طریق پروتکل قدیمی‌تر thrift.
سرورهای زمان اجرا (پردازشگرهای پیام و روترها) که از طریق پروتکل قدیمی‌تر thrift با کاساندرا ارتباط برقرار می‌کنند.

وضعیت زمان اجرا در این مرحله	وضعیت مدیریت در این مرحله
زمان اجرا کاملاً کاربردی	مدیریت کاملاً کاربردی

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

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

کاساندرا را به استفاده از LeveledCompactionStrategy تغییر دهید.
پشتیبان‌گیری از کاساندرا با استفاده از Apigee
در صورت امکان، از گره‌های کاساندرا در ماشین مجازی اسنپ‌شات بگیرید.
یک فایل پیکربندی ارتقاء کاساندرا روی هر گره کاساندرا در /opt/apigee/apigee-cassandra/cass_upgrade.conf با محتوای زیر ایجاد کنید:
```
# IP Address of node
HOSTIP=10.0.0.1

# Username for running Cassandra queries. Optional. Can be skipped if you have not enabled Cassandra authentication.
CASS_USERNAME=<cassuser>

# Password for running Cassandra queries. Optional. Can be skipped if you have not enabled Cassandra authentication.
CASS_PASSWORD=<casspass>

# Port for connecting to Cassandra via thrift. Optional. Defaults to 9160 if skipped.
CASS_PORT=9160

# Port for connecting to Cassandra via CQL. Optional. Defaults to 9042 if skipped.
CASS_CQL_PORT=9042

# Directory to be used by Cassandra upgrade scripts. Optional. Defaults to /tmp/cass_upgrade_scripts if skipped.
# Note that if upgrade is successful, this directory is deleted via root user - so provide a directory accordingly.
CASS_TMP_DIR=/tmp/cass_upgrade_scripts
    
```
اگر فایل در /opt/apigee/apigee-cassandra/cass_upgrade.conf ایجاد نشد، فایل /opt/silent.conf را با محتوای یکسان در هر گره کاساندرا ایجاد کنید.
احتیاط: نصب‌کننده‌ی ارتقاء Apigee در مکان‌های ذکر شده در بالا به دنبال فایل می‌گردد. اگر فایل در هیچ یک از مکان‌های ذکر شده در بالا وجود نداشته باشد، ارتقاء با پیامی مانند زیر ناموفق خواهد بود:
```
could not read env location: '/opt/apigee/apigee-cassandra/cass_upgrade.conf'
file does not exist or cannot be sourced
could not read env location: '/opt/silent.conf'
file does not exist or cannot be sourced
```
اگر این اتفاق بیفتد، ارتقاء با شکست مواجه می‌شود اما سرویس کاساندرا روی گره احتمالاً در حالت متوقف شده قرار خواهد گرفت. می‌توانید سرویس کاساندرا را طبق معمول شروع کنید و با قرار دادن فایل پیکربندی در هر یک از مکان‌های مورد انتظار، ارتقاء را دوباره امتحان کنید. علاوه بر این، اگر فایل پیدا شود اما پیکربندی‌های ارائه شده نادرست باشند (به عنوان مثال، اعتبارنامه‌های کاساندرا نادرست باشند)، ارتقاء با خطایی مانند زیر با شکست مواجه خواهد شد:
```
Error in PREIN scriptlet in rpm package apigee-cassandra-X.XX.XX-X.X.XXXX.noarch
```
در این حالت، به طور مشابه، اگر سرویس کاساندرا هنگام عدم موفقیت ارتقا متوقف شده است، آن را شروع کنید و پس از اصلاح پیکربندی‌های موجود در فایل، دوباره ارتقا را امتحان کنید.
اگر از ویژگی SmartDocs پورتال توسعه‌دهندگان Apigee Drupal 7 استفاده می‌کنید، با دانلود مدل‌های خود در قالب JSON از رابط کاربری پورتال توسعه‌دهندگان، از هر یک از آنها خروجی بگیرید . این مدل‌ها پس از به‌روزرسانی سرورهای مدیریت، باید دوباره به Apigee وارد شوند.
اطمینان حاصل کنید که پورت‌های ۹۱۶۰ و ۹۰۴۲ از تمام اجزای Edge به گره‌های Cassandra قابل دسترسی هستند، اگر از قبل وجود ندارند. برای اطلاعات بیشتر به الزامات پورت مراجعه کنید.

مرحله ۲: تغییر مسیر ترافیک از مرکز داده اول

ترافیک ورودی زمان اجرا و مدیریت از مرکز داده اول را مسدود کنید.
تمام ترافیک زمان اجرا و APIهای مدیریتی را به سایر مراکز داده کاربردی هدایت کنید.
تأیید کنید که ترافیک زمان اجرا و مدیریت با موفقیت توسط سایر DC(ها) مدیریت می‌شوند.

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

تمام گره‌های کاساندرا را در مرکز داده، یکی یکی ارتقا دهید. دستورات زیر را روی هر گره، یکی یکی اجرا کنید:
```
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
```
پس از به‌روزرسانی یک گره، دستور زیر را روی گره اجرا کنید تا قبل از ادامه، برخی اعتبارسنجی‌ها انجام شود:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra validate_upgrade -f configFile
```
خروجی دستور بالا چیزی شبیه به این خواهد بود:
```
Cassandra version is verified - [cqlsh 5.0.1 | Cassandra 3.11.16 | CQL spec 3.4.4 | Native protocol v3] Metadata is verified
```
پس از اتمام ارتقا، دستور post_upgrade زیر را روی هر گره کاساندرا یکی یکی اجرا کنید:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra post_upgrade
```

وضعیت زمان اجرا در این مرحله	وضعیت مدیریت در این مرحله
ترافیک زمان اجرا در مراکز داده در حال ارتقاء مسدود شده است زمان اجرا کاملاً کاربردی در سایر مراکز داده	ترافیک مدیریتی در مراکز داده در حال ارتقا مسدود شده است. عملکرد مدیریتی زیر پس از ارتقاء کاساندرا در سایر مراکز داده، دچار اختلال می‌شود: API مدیریت برای ایجاد محصول API با محیط API مدیریتی برای به‌روزرسانی یک محصول API با محیط API مدیریت برای حذف یک سازمان

وضعیت زمان اجرا در این مرحله

وضعیت مدیریت در این مرحله

ترافیک زمان اجرا در مراکز داده در حال ارتقاء مسدود شده است
زمان اجرا کاملاً کاربردی در سایر مراکز داده

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

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

تمام گره‌های مدیریتی در مرکز داده را ارتقا دهید:

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

وضعیت زمان اجرا در این مرحله	وضعیت مدیریت در این مرحله
ترافیک زمان اجرا در مراکز داده در حال ارتقاء مسدود شده است زمان اجرا کاملاً کاربردی	ترافیک مدیریتی در مراکز داده در حال ارتقا مسدود شده است. عملکرد مدیریتی زیر پس از ارتقاء کاساندرا کاهش می‌یابد: API مدیریت برای ایجاد محصول API با محیط API مدیریتی برای به‌روزرسانی یک محصول API با محیط API مدیریت برای حذف یک سازمان

وضعیت زمان اجرا در این مرحله

وضعیت مدیریت در این مرحله

ترافیک زمان اجرا در مراکز داده در حال ارتقاء مسدود شده است
زمان اجرا کاملاً کاربردی

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

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

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

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

وضعیت زمان اجرا در این مرحله	وضعیت مدیریت در این مرحله
ترافیک زمان اجرا در مراکز داده در حال ارتقاء مسدود شده است زمان اجرا کاملاً کاربردی در سایر مراکز داده	ترافیک مدیریتی در مراکز داده در حال ارتقا مسدود شده است. عملکرد مدیریتی زیر پس از ارتقاء کاساندرا در سایر مراکز داده، دچار اختلال می‌شود: API مدیریت برای ایجاد محصول API با محیط API مدیریتی برای به‌روزرسانی یک محصول API با محیط API مدیریت برای حذف یک سازمان

وضعیت زمان اجرا در این مرحله

وضعیت مدیریت در این مرحله

ترافیک زمان اجرا در مراکز داده در حال ارتقاء مسدود شده است
زمان اجرا کاملاً کاربردی در سایر مراکز داده

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

مرحله ۶: هدایت ترافیک به مرکز داده اول

پس از ارتقاء مرکز داده First با Cassandra، اجزای زمان اجرا و سرور مدیریت، ترافیک زمان اجرا و مدیریت را به مرکز داده First دوباره فعال کنید.
اطمینان حاصل کنید که ترافیک زمان اجرا و مدیریت در سراسر DCها با موفقیت انجام می‌شود.

مرحله ۷: سایر مراکز داده را ارتقا دهید

مراحل ۱ تا ۶ را روی مراکز داده باقی‌مانده، یکی‌یکی با هدایت ترافیک به خارج از این مراکز داده، به‌روزرسانی نرم‌افزار Apigee و فعال‌سازی مجدد ترافیک در چنین مراکز داده‌ای، تکرار کنید.

مرحله ۸: اجرای مجدد مرحله ارتقاء در تمام گره‌های مدیریتی

دستور ارتقاء زیر را در تمام گره‌های مدیریتی در مراکز داده دوباره اجرا کنید:

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

مرحله ۹ - [اختیاری] وارد کردن اسمارت‌داک‌هایی که قبلاً اکسپورت شده‌اند

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

فقط در صورتی که از پورتال توسعه‌دهندگان مبتنی بر دروپال ۷ استفاده می‌کنید و از ویژگی smartdocs بهره می‌برید، باید این کار را انجام دهید.

وضعیت زمان اجرا در این مرحله	وضعیت مدیریت در این مرحله
زمان اجرا کاملاً کاربردی	مدیریت کاملاً کاربردی

مرحله 10 - جداول بلااستفاده را حذف کنید

دستور زیر را برای حذف جداول قدیمی و بلااستفاده از کلاستر کاساندرا اجرا کنید. تا زمانی که این دستور اجرا نشود، نمی‌توانید از برخی ویژگی‌های کاساندرا (مانند راه‌اندازی احراز هویت جدید - مکانیسم‌های احراز هویت قدیمی به کار خود ادامه خواهند داد) استفاده کنید. این دستور فقط می‌تواند روی یک گره در کلاستر اجرا شود.

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

مرحله 11 - تمام اجزای باقی مانده Edge و سایر اجزای Private Cloud 4.52.02 را ارتقا دهید

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

در این مرحله، اگر از نسخه‌های قدیمی‌تر از Edge برای Private Cloud 4.52.01 مانند زیر ارتقا می‌دهید، مراحل اضافی برای ارتقاء Qpid و Postgres را به ترتیب انجام دهید و اجزای باقی مانده را طبق این مراحل ارتقا دهید.

ارتقا به Qpid J-Broker

اگرچه Edge برای Private Cloud نسخه ۴.۵۲.۰۲ شامل ارتقاء به Qpid نمی‌شود، اما اگر از نسخه‌های قدیمی‌تر از ۴.۵۲.۰۱ در حال ارتقاء هستید، باید مراحل ارتقاء QPID را دنبال کنید.

اگر در حال ارتقا از Edge for Private Cloud نسخه ۴.۵۱.۰۰ یا ۴.۵۲.۰۰ به ۴.۵۲.۰۲ هستید، لازم است مراحل اضافی ارتقاء Qpid را دنبال کنید. لطفاً اگر در حال ارتقا از نسخه ۴.۵۱.۰۰ یا ۴.۵۲.۰۰ به ۴.۵۲.۰۲ هستید، به بخش ارتقاء Qpid مراجعه کنید.
اگر در حال ارتقا از Edge for Private Cloud نسخه ۴.۵۲.۰۱ به ۴.۵۲.۰۲ هستید، باید از آخرین نسخه Qpid Broker استفاده کنید و هیچ مرحله اضافی برای ارتقاء Qpid لازم نیست.

رابط کاربری جدید اج

این بخش ملاحظات مربوط به رابط کاربری Edge را فهرست می‌کند. برای اطلاعات بیشتر، به رابط کاربری جدید Edge برای Private Cloud مراجعه کنید.

رابط کاربری Edge را نصب کنید

پس از اتمام نصب اولیه، Apigee توصیه می‌کند که Edge UI را نصب کنید، که یک رابط کاربری بهبود یافته برای توسعه‌دهندگان و مدیران Apigee Edge برای Private Cloud است.

توجه داشته باشید که رابط کاربری Edge مستلزم آن است که احراز هویت پایه را غیرفعال کنید و از یک IDP مانند SAML یا LDAP استفاده کنید.

برای اطلاعات بیشتر، به نصب رابط کاربری جدید Edge مراجعه کنید.

رابط کاربری Edge را به‌روزرسانی کنید

برای به‌روزرسانی مؤلفه رابط کاربری Edge، نسخه Edge برای Private Cloud که از آن ارتقا می‌دهید را در نظر بگیرید:

از نسخه ۴.۵۱.۰۰ به ۴.۵۲.۰۰ (با رابط کاربری جدید اج که از قبل نصب شده است): از دستورالعمل‌های ارتقاء در این بخش برای کامپوننت edge-management-ui استفاده کنید.

به‌روزرسانی با Apigee mTLS

برای به‌روزرسانی Apigee mTLS ، مراحل زیر را انجام دهید:

برگرداندن یک به‌روزرسانی به حالت قبل

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

اگر به دلیل این خطا مجبور شدید به‌روزرسانی را به نسخه قبلی برگردانید، برای دستورالعمل‌های دقیق‌تر به بخش «بازگشت به نسخه ۴.۵۲.۰۰» مراجعه کنید.

ثبت اطلاعات به‌روزرسانی

به طور پیش‌فرض، ابزار update.sh اطلاعات لاگ را در مسیر زیر می‌نویسد:

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

اگر شخصی که ابزار update.sh اجرا می‌کند به آن دایرکتوری دسترسی نداشته باشد، گزارش را به عنوان فایلی با نام update_username.log در دایرکتوری /tmp می‌نویسد.

اگر به /tmp دسترسی نداشته باشید، ابزار update.sh با شکست مواجه می‌شود.

به‌روزرسانی بدون قطعی

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

به‌روزرسانی بدون قطعی فقط با پیکربندی ۵ گره‌ای و بزرگتر امکان‌پذیر است.

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

دستگاه‌ها را به ترتیب صحیح نصب، همانطور که در ترتیب به‌روزرسانی دستگاه توضیح داده شده است، به‌روزرسانی کنید.
وقتی زمان به‌روزرسانی روترها فرا رسید، هر یک از روترها را انتخاب کرده و آن را از دسترس خارج کنید، همانطور که در فعال/غیرفعال کردن قابلیت دسترسی سرور (پردازنده پیام/روتر) توضیح داده شده است.
روتر انتخاب شده و تمام اجزای Edge دیگر را که روی همان دستگاه روتر قرار دارند، به‌روزرسانی کنید. تمام پیکربندی‌های Edge، یک روتر و پردازنده پیام را روی یک گره نشان می‌دهند.
روتر را دوباره قابل دسترسی کنید.
مراحل ۲ تا ۴ را برای روترهای باقی مانده تکرار کنید.
به‌روزرسانی را برای هر دستگاه باقی‌مانده در نصب خود ادامه دهید.

قبل و بعد از آپدیت به نکات زیر توجه کنید:

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

از یک فایل پیکربندی بی‌صدا استفاده کنید

شما باید یک فایل پیکربندی بی‌صدا را به دستور update ارسال کنید. فایل پیکربندی بی‌صدا باید همان فایلی باشد که برای نصب Edge 4.50.00 یا 4.51.00 استفاده کرده‌اید.

به‌روزرسانی به نسخه ۴.۵۲.۰۲ روی یک گره با اتصال اینترنت خارجی

برای به‌روزرسانی اجزای Edge روی یک گره، از روش زیر استفاده کنید:

در صورت وجود، هرگونه cron jobs پیکربندی شده برای انجام عملیات تعمیر در کاساندرا را تا پس از اتمام به‌روزرسانی غیرفعال کنید.
برای نصب Edge RPMها، به عنوان root وارد گره خود شوید.
توجه: اگرچه نصب RPM به دسترسی روت نیاز دارد، اما می‌توانید پیکربندی Edge را بدون دسترسی روت انجام دهید.
yum-utils و yum-plugin-priorities را نصب کنید:
نکته: اگر سیستم عامل شما RHEL 8.0 - 8.6 است، از این مرحله صرف نظر کنید.
```
sudo yum install yum-utils
sudo yum install yum-plugin-priorities
```
SELinux را همانطور که در نصب ابزار Edge apigee-setup توضیح داده شده است، غیرفعال کنید.
اگر روی Oracle 7.x نصب می‌کنید ، دستور زیر را اجرا کنید:
```
sudo yum-config-manager --enable ol7_optional_latest
```

اگر روی AWS نصب می‌کنید ، دستورات yum-configure-manager زیر را اجرا کنید:

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

اگر در حال حاضر از Edge 4.51.00 استفاده می‌کنید:
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.52.02.sh
```
2. با اجرای دستور زیر، ابزار apigee-service و وابستگی‌های Edge 4.52.02 را نصب کنید:
```
sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord
```
  که در آن uName:pWord نام کاربری و رمز عبوری است که از Apigee دریافت کرده‌اید. اگر pWord وارد نکنید، از شما خواسته می‌شود که آن را وارد کنید.
  به طور پیش‌فرض، نصب‌کننده بررسی می‌کند که آیا جاوا ۱.۸ را نصب کرده‌اید یا خیر. اگر این کار را نکنید، نصب‌کننده آن را برای شما نصب می‌کند.
  از گزینه JAVA_FIX برای تعیین نحوه مدیریت نصب جاوا استفاده کنید. JAVA_FIX مقادیر زیر را می‌گیرد:
  - I : OpenJDK 1.8 (پیش‌فرض) را نصب کنید.
  - C : بدون نصب جاوا ادامه دهید.
  - Q : خروج. برای این گزینه، باید خودتان جاوا را نصب کنید.
3. همانطور که در مثال زیر نشان داده شده است، apigee-service برای به‌روزرسانی ابزار apigee-setup استفاده کنید:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-setup update
```
4. ابزار apigee-validate را در سرور مدیریت به‌روزرسانی کنید، همانطور که در مثال زیر نشان داده شده است:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-validate update
```
5. ابزار apigee-provision را در سرور مدیریت به‌روزرسانی کنید، همانطور که در مثال زیر نشان داده شده است:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-provision update
```
6. با اجرای دستور زیر، ابزار update را روی گره‌های خود اجرا کنید:
```
/opt/apigee/apigee-setup/bin/update.sh -c component -f configFile
```
  این کار را به ترتیبی که در بخش «ترتیب به‌روزرسانی دستگاه» توضیح داده شده است، انجام دهید.
  کجا:
  - component کامپوننت Edge برای به‌روزرسانی است. مقادیر ممکن عبارتند از:
    - cs : کاساندرا
    - edge : همه اجزای لبه به جز رابط کاربری لبه: سرور مدیریت، پردازنده پیام، روتر، سرور Qpid، سرور Postgres
    - ldap : اوپن‌LDAP
    - ps : پست‌گرس‌کیوال
    - qpid : qpidd
    - sso : Apigee SSO (اگر SSO را نصب کرده‌اید)
    - ue : رابط کاربری جدید اج
    - ui : رابط کاربری کلاسیک اج
    - zk : نگهبان باغ وحش
  - configFile همان فایل پیکربندی است که شما برای تعریف اجزای Edge خود در طول نصب نسخه ۴.۵۰.۰۰ یا ۴.۵۱.۰۰ استفاده کردید.
  شما می‌توانید با تنظیم component روی "all"، update.sh برای همه کامپوننت‌ها اجرا کنید، اما فقط در صورتی که یک پروفایل نصب Edge all-in-one (AIO) داشته باشید. برای مثال:
```
/opt/apigee/apigee-setup/bin/update.sh -c all -f ./sa_silent_config
```
7. اگر قبلاً این کار را نکرده‌اید، اجزای رابط کاربری Edge را روی تمام گره‌هایی که آنها را اجرا می‌کنند، مجدداً راه‌اندازی کنید:
```
/opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart
```
8. با اجرای ابزار apigee-validate روی سرور مدیریت، همانطور که در بخش «تست نصب» توضیح داده شده است، به‌روزرسانی را آزمایش کنید.

اگر بعداً تصمیم به بازگرداندن به‌روزرسانی گرفتید، از روشی که در «بازگرداندن به‌روزرسانی ۴.۵۲.۰۲» توضیح داده شده است، استفاده کنید.

به‌روزرسانی به ۴.۵۲.۰۲ از یک مخزن محلی

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

پس از ایجاد مخزن محلی Edge، دو گزینه برای به‌روزرسانی Edge از مخزن محلی دارید:

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

برای به‌روزرسانی از یک مخزن محلی ۴.۵۲.۰۲:

همانطور که در بخش «ایجاد مخزن محلی Apigee» در نصب ابزار Edge apigee-setup توضیح داده شده است، یک مخزن محلی ۴.۵۲.۰۲ ایجاد کنید.
توجه: اگر از قبل یک مخزن موجود دارید، می‌توانید مخزن ۴.۵۲.۰۲ را همانطور که در بخش «به‌روزرسانی مخزن محلی Apigee» در بخش «نصب ابزار apigee-setup اج » توضیح داده شده است، به آن اضافه کنید.
برای نصب apigee-service از فایل .tar :
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.52.02.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.52.02.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.52.02.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos
```
  Notice that you include the path to the repos directory in this command.
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.52.02.sh file to /tmp/bootstrap_4.52.02.sh :
```
/usr/bin/curl http://uName:pWord@remoteRepo:3939/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.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.52.02.sh apigeerepohost=remoteRepo:3939 apigeeuser=uName apigeepassword=pWord apigeeprotocol=http://
```
  Where uName:pWord are the repo username and password.
Use apigee-service to update the apigee-setup utility, as the following example shows:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-setup update 
```
Update the apigee-validate utility on the Management Server, as the following example shows:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-validate update
```
Update the apigee-provision utility on the Management Server, as the following example shows:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-provision update
```
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
```
کجا:
- 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.50.00 or 4.51.00 installation.
  NOTE: The configuration file must be readable by the "apigee" user. To change the owner, use the following command:
```
chown apigee:apigee configFile
```
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
```

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

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.52.02 .

Order of machine update - upgrade from 4.51.00 (or) 4.52.00 (or) 4.52.01

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

You must update all ZooKeeper nodes across data centers before upgrading all other components. If you are upgrading from Edge Private Cloud 4.51.00 (or) 4.52.00, you will also need to follow additional steps to upgrade zookeeper .
You must update Postgresql across all the data centers. If you are upgrading from Edge Private Cloud 4.51.00, you will also need to follow additional steps to upgrade postgres .
You must update LDAP nodes across all the data centers.
You must update all Cassandra, Management Server, Message Processor and Router nodes, one data center at a time , until all data centers are upgraded.
You must update edge-qpid-server & edge-postgres-server components across all data centers.
You must upgrade Qpid nodes across all data centers. If you are upgrading from Edge Private Cloud 4.51.00 (or) 4.52.00, you will also need to follow additional steps to upgrade Qpid .
Update Edge UI and New Edge UI, SSO nodes across all data centers.
There is no separate step to update Monetization. It is updated when you specify the -c edge option.
Note: After you update the Edge UI component, you must restart the Edge UI service, as described in the update installation instructions.

1-node standalone upgrade

To upgrade a 1-node standalone configuration to 4.52.02:

Update all components:

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

(If you installed apigee-adminapi ) Updated 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.

Update Zookeeper on machine 1:

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

Update Postgres on machine 2:

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

Update LDAP on machine 1:

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

Update Cassandra on machine 1:

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

Update Edge components on machine 1 and 2:

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

Update Qpid on Machine 2:

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

Update the UI on machine 1:

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

(If you installed apigee-adminapi ) Updated the apigee-adminapi utility on machine 1:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
(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 .

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.

Update ZooKeeper on machines 1, 2, and 3:

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

Update Postgres on machine 4:

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

Update Postgres on machine 5:

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

Update LDAP on machine 1:

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

Update Cassandra on machines 1, 2, and 3:

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

Update Edge components on machines 1, 2, 3, 4, 5:

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

Update Qpid on machine 4:

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

Update Qpid on machine 5:

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

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
```
(If you installed apigee-adminapi ) Updated the apigee-adminapi utility on machine 1:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
(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 .
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 cluster upgrade

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

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

Update ZooKeeper on machine 1, 2, and 3:

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

Update Postgres on machine 8:

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

Update Postgres on machine 9:

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

Update LDAP on machine 1:

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

Update Cassandra on machine 1, 2, and 3:

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

Update Edge components on machines 1, 4, 5, 6, 7, 8, and 9 in that order:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

Update Qpid on machines 6 and 7:

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

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

(If you installed apigee-adminapi ) Update the apigee-adminapi utility on machine 1:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
(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 .
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 cluster upgrade

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

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

Update ZooKeeper on machines 1, 2, and 3:

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

Update Postgres on machine 8:

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

Update Postgres on machine 9:

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

Update LDAP on machines 4 and 5:

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

Update Cassandra on machines 1, 2, and 3:

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

Update Edge components on machines 6, 7, 10, 11, 12, 13, 8, and 9 in that order:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

Update Qpid on machines 12 and 13:

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

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
```
(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
```
(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 .
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 cluster upgrade

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

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

Update ZooKeeper on machines 1,2,3,7,8,9 in both DCs:

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

Update Postgres on machines 6,12 in both DCs:

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

Update LDAP on machines 1,7 in both DCs:

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

Block the traffic in DC-1 and make sure all the traffic rerouted to other DC-2

Update Update Cassandra on machine 1,2,3 in DC-1:

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

Update Management Server on machine 1 in DC-1:

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

Update Router, Message Processor on machine 2,3 in DC-1:

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

Unblock the traffic in DC-1 and validate the DC-1 and proceed with the DC-2 by blocking traffic in DC-2 and reroute the traffic to DC-1

Update Cassandra on machine 7,8,9 in DC-2:

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

Update Management Server on machine 7 in DC-2:

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

Update Router, Message Processor on machine 8,9 in DC-2:

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

Unblock the traffic in DC-2 and now, both DCs will handle traffic
Re-run the update command in all the management-server across DCs on machine 1 & 7:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
Update edge-qpid-server & edge-postgres-server on machine 4,5,6,10,11,12 in both DCs:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

Update Qpid on machine 4,5,10,11 in both DCs:

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

Update either the new UI (ue) or classic UI (ui) in both DCs:

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

(If you installed apigee-adminapi) Update the apigee-adminapi in both DCs:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
(If you installed Apigee SSO) Update Apigee SSO nodes in both DCs:
```
/opt/apigee/apigee-setup/bin/update.sh -c sso -f configFile
```
Restart the new Edge UI (edge-management-ui) or classic Edge UI (edge-ui) component in both DCs:
```
/opt/apigee/apigee-service/bin/apigee-service [edge-ui|edge-management-ui] restart
```