Expressway 15.5.20以降のアップグレードチェックリスト

準備状況の確認でアップグレードが停止しました

証明書、TLS検証、またはピアIDの要件が失敗すると、再起動の前にインストーラが停止します。スタンドアロンノードはピアIDチェックに合格します。

ノード起動後のアラーム

クラスタデータベースの再暗号化のバーストにより、クラスタ通信障害アラームが発生する可能性があります。終了までの時間を与えます。引き続き稼働している場合はエスカレーションします。

管理者がサインインできません

この問題は、インストールの失敗とは別に扱ってください。期限切れ、再利用、または最初のログインパスワードによってセッションがブロックされます。これは、イメージの障害を意味するものではありません。

証明書またはピアIDの障害

1. 停止したノードから完全なシステムスナップショットをダウンロードします。そのスナップショットのtmpディレクトリにあるinstallimage.logを開きます。
2. メッセージがピアIDに関するものである場合は、IPアドレスとFQDNが混在していないか、または空のピアリストがないかを確認します。すべてのピアで1つの形式を使用し、レプリケーションを待機し、クラスタが正常であることを確認してから、再試行してください。ローリングアップグレードの途中でID形式を変更しないでください。
3. メッセージが証明書に関するものである場合は、リリースノートのルールと比較してください。システムFQDNはSAN内にあるか、またはSANが空のときにのみCN内にある必要があります。現在のSANはCNにフォールバックできません。
4. 正しいSANタイプで、必要なすべてのDNS名を使用して証明書を再発行します。埋め込みNULを含む名前を拒否します。
5. 新しい証明書が日付に準拠し、RSA 2048+またはP-256+で信頼され、SHA-2で署名されていることを確認します。ケースに秘密鍵を添付しないでください。
6. TLS検証をEnforcingに設定し、クラスタが正常であることを確認して、停止したノードでアップグレードを再試行します。
7. ローリングアップグレードは、そのノードが正常な状態になった後にのみ続行します。このチェックで1つのノードが停止している間は、残りのノードをアップグレードしないでください。

アップグレード中またはアップグレード直後のクラスタアラーム

1. アップグレード自体が完了し、ノードが目的のビルド（X15.5.20またはX15.5.21）上にあることを確認します。
2. イベントログで、ClusterDBフィールドの再暗号化に関するdeveloper.upgradeメッセージを確認し、「Saving migrated data to CDB」を確認します。
3. アラームがクリアされるまで待ちます。トレーニング資料には、再暗号化が完了すると消去されると記載されています。
4. 残っている場合は、各ピアからクラスタステータス、アラーム、およびスナップショットを収集します。ケースのメモにクラスタCookieやキー情報をコピーしないでください。

ノードが起動した後のサインインの問題

• Web UIがパスワードの変更にリダイレクトされます。現在のパスワードを入力する必要があります。また、新しいパスワードは異なるパスワードにする必要があります。これは、インストールまたは工場出荷時設定へのリセット後、およびローカルパスワードの有効期限が切れた後の最初のGUIログインで予期されます。
• SSHは、キーボードインタラクティブ/PAMが失敗したと通知し、シェルを開きません。期限切れのローカルパスワードを変更する必要があります。古いセッションは許可されていません。
• RESTは401を返します。期限切れのローカル管理者が必要です。イベントログに、APIレルムのパスワードの不一致またはtaa-chkpasswdエラーが記録される場合があります。パスワードを変更してから、再試行してください。
• 新しいパスワードが拒否されました。履歴（デフォルトは最後の12）に含まれているか、現在の複雑度ルールに失敗しています。
• LDAP管理者は必要な役割を失いました。設定したグループを、LDAPから返された正確なグループ名と比較します。部分一致または部分文字列一致では、ロールが付与されなくなりました。読み取り専用の管理者は、SAML IdP信頼を編集できません。
• 新規インストールまたは工場出荷時の初期状態へのリセットでは、工場出荷時のデフォルトのルートパスワードはありません。デフォルトのクレデンシャルを検索したり、配布したりしないでください。アップグレードしても、現在の管理者パスワードはクリアされません。

注意：工場出荷時状態へのリセットは、アップグレード/リカバリの手順ではありません。クラスタIDとクラスタCookieを削除します。クラスタリング解除が行われた後のシステムによるリセットや、一貫性のないクラスタデータベースでは、IPアドレスと管理者パスワードおよびルートパスワードが保持され、他の設定とログがクリアされて、ノードが一時証明書に戻されます。リリースノートで呼び出された場合、およびバックアップが存在する場合にのみ使用します。

TACケースが必要な場合に収集する証拠

1. 各ノードのソフトウェアバージョンとロール、および停止したノード。
2. 障害が発生したノードからの完全なシステムスナップショット（tmp/installimage.logを含む）。
3. サーバー証明書テキスト(openssl x509 -text -noout)。 秘密キーがありません。
4. クラスタステータス、アラーム、およびxConfiguration Cluster TlsVerifyでPermissiveとEnforceのどちらが表示されるか。
5. アップグレードのイベントログ行、および関連する場合はsshdまたはhttpd認証の失敗。パスワードとCookieを修正します。
6. ローカル、LDAP、SAMLのどの管理者を使用していても、Smart Licensingと任意のAPIの自動化を使用できます。

アップグレード後

すべてのノード

1. Versionは目的のビルドです。2026年10月のPHP脆弱性へのアップグレードにはX15.5.21を使用してください。X15.5.20にはこの修正は含まれていません。
2. ノードは管理アドレスで到達可能で、Web UIがロードされます。
3. 新しいハードウェア、ディスク、またはアプリケーションアラームは発生しません。（クラスタ通信アラームは、再暗号化後にクリアされます）。
4. クラスタが安定した後、新しいバックアップが作成されます。

クラスタのみ

1. クラスタ内のすべてのピアが稼働しており、レプリケーションは正常です。
2. ピアはTCP 4371および4372で相互TLSと通信します（有効なクライアント証明書のない接続は失敗します）。
3. クラスタTlsVerifyが適用されています。

   Permissiveはサポートされていません。従来のPermissive値は引き続き表示できますが、検証をバイパスしません。Enforcingを設定し、クラスタが正常であることを確認します。

4. ファイアウォールは、ピアアドレスからのTCP 4371のみを引き続き許可します。

5. アップロードしたログまたはスナップショットのメモに、クラスターCookieまたは診断シークレットが表示されません。

使用中のサービスのチェック