システムダウンタイムなしでSLES 15 SP5からSP6に移行する方法
SLES 15 SP5からSP6への移行中にサービスを継続的に利用できるようにするための、テスト済みのSLE HAローリングアップグレード、ノードごとのチェック、および明確な単一サーバーダウンタイムに関する注意点について学びましょう。
SLES 15 SP5 クラスタを SP6 に移行する際にアプリケーションを稼働させたままにすることは可能ですが、単一のオペレーティングシステムインスタンスを中断なくアップグレードして再起動することはできません。SUSE は SP5 から SP6 へのサービスパック移行をサポートしていますが、オンライン移行プロセスではシステムの再起動が必要です。サービスのダウンタイムを回避するには、サポートされている SUSE Linux Enterprise High Availability (SLE HA) クラスタでノードを 1 つずつアップグレードするか、代替の SP6 環境を構築してトラフィックをそちらに移行してください。各ホストが利用できない間も、サービスが正常に動作する場所が必要です。
この初心者向けガイドでは、SLE HAクラスタのローリングアップグレード手順に焦点を当てています。また、サーバーが1台しかない場合の対処方法、変更前に確認すべき事項、サービスが正常に動作しているかどうかを確認する方法についても解説しています。ワークロードを移動するための具体的なコマンドと順序は、クラスタのリソース、ストレージ、およびアプリケーションによって異なります。
サービスパックの移行では、ソースシステムが稼働中にシステムパッケージが置き換えられます。SUSEではこれをオンライン移行と呼んでいます。インストールメディアからの起動の必要性は軽減されますが、公式の手順では移行が成功した後にシステムを再起動するよう指示されています。オンライン移行は、同じホストが継続的にリクエストを処理するライブアップグレードとは異なります。
クラスタ化されたサービスの場合、ローリングアップグレードとは、1つのノードをサービスから外し、移行と再起動を行い、クラスタに戻してから、次のノードで同じ手順を繰り返すことを意味します。フェイルオーバーが正常に機能し、残りの容量が十分であれば、アプリケーションは別のノードから引き続き利用可能です。フェイルオーバーによってアクティブなセッションが一時的に中断される可能性があるため、「高可用性」によってすべての接続が影響を受けずに維持されると想定するのではなく、ユーザー向けサービスの可用性を測定してください。
SUSE は、SLES 15 SP5 を SP6 のサポート対象ソースとして、オンラインとオフラインの両方でリストしています。サポート対象パスについては、SLES 15 SP6 アップグレードパスガイドに記載されています。SUSE HA のドキュメントでは、同じメジャーリリース内のサービスパック間でのクラスタのローリングアップグレードがサポートされています。SLE HA クラスタアップグレードガイドを参照してください。
zypper migration SUSE Managerのクライアント移行ワークフローに従ってください。SUSEは、YaSTオンライン移行をSUSE Managerクライアント上で直接使用しないよう推奨しています。サービスがデータベースまたはその他のステートフルアプリケーションである場合は、アプリケーションの互換性とデータレプリケーションを別々の作業フローとして扱ってください。オペレーティングシステムの移行パスは、データベースを自動的にアップグレードしたり、そのレプリケーションおよびフェイルオーバー設計の安全性を証明したりするものではありません。
すべてのノードがSLES 15 SP5で、SLE HA拡張機能およびその他のモジュールまたは製品が正しく登録されていることを確認してください。移行対象リストは、インストールされている製品と拡張機能によって異なります。SP6ターゲットが表示されない場合は、登録、リポジトリ、または拡張機能の可用性に問題がある可能性があります。ターゲットを表示させるためだけに、リポジトリパスを強制的に変更しないでください。
登録済みのシステムの場合、以下の読み取り専用チェックによってその状態を把握することができます。
cat /etc/os-release
sudo SUSEConnect --status
sudo zypper lr -u
すべてのノードにインストールされているSLESおよびSLE HA製品、リポジトリ、アーキテクチャを比較します。ホストがSUSE Managerによって管理されている場合は、以下の手順を直接実行するのではなく、対応するクライアント移行手順を使用してください。
SUSEでは、アップグレード前にソースシステムが最新のパッチレベルになっていることを要求しています。最新のSP5メンテナンスアップデートを適用し、SP6リリースノートでパッケージ、モジュール、およびアプリケーションの変更点を確認してください。SUSEのアップグレード準備手順では、最新のバックアップとリリースノートの確認も求められています。
システム構成とアプリケーションデータをバックアップし、バックアップが復元できることを確認します。ネットワークインターフェイス、ストレージ、クラスタリソース、サードパーティリポジトリ、アプリケーションの健全性チェックなど、本番環境と一致するステージングクラスタで手順全体をテストします。各ノードでの移行と再起動にかかる時間を記録し、変更ウィンドウを推定できるようにします。
ノードを削除する前に、クラスターが正常であり、未解決のリソース障害がないことを確認してください。別のノードがサービスを実行でき、必要なストレージをマウントまたはアクセスでき、想定されるトラフィックを処理できることを確認してください。ノードが1つ失われるとCPU、メモリ、ネットワーク、またはストレージに過負荷がかかる場合は、ダウンタイムがないと主張するのではなく、容量を追加するか、負荷を軽減するか、メンテナンス期間をスケジュールしてください。
クラスタフェンシングが、確立されたHA設計に従って構成され、正常に機能していることを確認してください。フェンシングは、信頼できないノードを隔離することで共有リソースを保護します。アップグレードを容易にするためにフェンシングを無効にすると、スプリットブレインのリスクが生じる可能性があります。ノードが再起動後に復旧しない場合に備えて、コンソールまたは帯域外アクセスを利用できるようにしておいてください。
以下の手順を計画の概要として活用してください。ご使用のSLE HAバージョンとリソース設定に合わせて、必ず手順に従ってください。リソース管理手順をそのまま本番環境にコピーしないでください。
crm statusクラスタの状態を検査する 1 つの方法が文書化されています。crm cluster stop。sudo zypper migration。提示された SP6 ターゲットとリポジトリの変更を確認します。確認する前に、提案されたパッケージ アクション、特に削除またはダウングレードするパッケージをよく読んでください。このコマンドライン パスについては、SLES の公式オンライン移行手順書に記載されています。crm cluster start。crm statusまたは Hawk2 をチェックし、ノードがリソース障害なく再参加することを確認します。SUSEは、異なるバージョンが混在するクラスタノードはローリングアップグレード期間中のみ一時的にサポートされ、アップグレードは1週間以内に完了する必要があると述べています。異なるバージョンが混在するクラスタを無期限に放置するのではなく、短期間で計画的にアップグレードを進めてください。最後に、すべてのノードがSP6を実行していることを確認し、クラスタとアプリケーションの健全性をチェックし、ログとリポジトリの登録状況を確認してください。
変更前に、測定可能な成功条件を定義します。例えば、各ノードのメンテナンス中、サービスの外部ヘルスチェックが継続的に合格し、エラー率が合意されたしきい値内に収まり、1つのノードが利用不能な状態でも代表的なユーザー トランザクションが成功する、といった条件です。フェイルオーバーのギャップ、セッションのドロップ、キューイングされた作業、パフォーマンスの低下などを記録します。エンドポイントは稼働状態を維持していたものの、重要なワークフローが失敗した場合は、移行はサービス レベルの目標を達成していません。
ローリングアップグレードは、適切に設計されたサービスであれば、個々のサーバーが再起動している間も利用可能に維持できます。ただし、セッションの中断を保証したり、容量不足のクラスタを補ったり、移行された各ホストの再起動をなくしたりすることはできません。シングルノード構成、テスト済みのレプリケーションがないステートフルアプリケーション、またはサポートされていない拡張機能を持つクラスタの場合は、計画的なメンテナンス期間を使用するか、本番トラフィックを移行する前に代替環境を構築して検証してください。
SLES 15 SP5からSP6への移行中にサービスを継続的に利用できるようにするための、テスト済みのSLE HAローリングアップグレード、ノードごとのチェック、および明確な単一サーバーダウンタイムに関する注意点について学びましょう。
Ubuntu Server 24.04 上で Pi-hole を設定し、dnscrypt-proxy を使用して DNS-over-HTTPS を利用するようにしてから、ローカルのアップストリームを確認し、一般的な DNS の競合を回避します。
SSH X11転送経由のYaST GUIの不具合をトラブルシューティングします。DISPLAYをテストし、既知のQt XIOエラーを修正し、SSH設定を確認し、必要に応じてncursesに切り替えます。
SLES 15 上に SUSE RMT をセットアップし、SCC メタデータを同期し、選択したリポジトリをミラーリングし、HTTPS 経由でクライアントを登録し、SMT からの移行における制限事項を理解する。
Pardus Linux 23でサウンドカードが認識されない場合のトラブルシューティングを行います。ALSA検出、カーネルモジュール、オーディオサービス、出力プロファイル、ファームウェア、およびアップデートを安全に確認します。
Pardus KVMゲストが1024x768でフリーズしてしまう問題を解決するには、仮想GPU、SPICEエージェント、X11またはWaylandセッションを確認し、より高いディスプレイモードが正しく動作していることを確認してください。
Debianにおいて、キーベースのSSH、/etc/fstab、systemdネットワークオプション、自動マウント、および検証手順を用いて、起動時にリモートSSHFSディレクトリを自動的にマウントします。
SLESアップグレード中に「メモリを割り当てできません」というエラーが発生した場合のトラブルシューティングを行います。RAM、スワップ、OOMログ、およびプロセス制限を確認し、パッケージトランザクションを中断することなく復旧します。
Harmonica OS (HamoniKR) タブレットにおけるタッチオフセット、回転、およびディスプレイマッピングのトラブルシューティングを行います。X.Org と libinput の修正を比較し、安全にテストを行い、キャリブレーションが役に立たない場合を把握します。
既存の Debian 12 スワップパーティションを、dm-crypt、起動ごとに生成される新しいランダムキー、/etc/crypttab、/etc/fstab、および安全な検証手順を使用して暗号化します。