BeeX Advent Calendar 2024 19日目 の記事です
久しぶりのブログ
毎月ブログを書くぞー！と宣言した後全くブログを更新しなかった意志の弱い者です。
今回は、Advent Calendarということで、自分を追い込むためエントリーしてブログを投稿しますので、お手柔らかにお願いします
今回の内容
今年を振り返ると、SAPシステム（S4/HANA）の冗長性や可用性を高めるための構築作業や提案などを行っていました。
そして、10月末にLifeKeeper技術者認定制度の制度も始まり、今まで頑張ってきたことが身についているのか？など答え合わせもしたくて、認定資格も取得してきました！
なので、今回のブログでLifeKeeper周りをいろいろまとめてみようかなと思います。
認定資格のリンクは以下です。ウェビナーで学習後、試験を実施する形になります。
興味がある方はこちらもご確認ください♪
LifeKeeper技術者認定制度を始めます！
まずは、簡単にLifeKeeperについて口述で記載しつつ、どんなことに気を付けなければいけないのかを記載しようと思います。
LifeKeeperとは？
サイオステクノロジー社（以下、SIOS社）が提供しているソフトウェアです。
システムの障害を監視し、稼動系に障害が生じた場合に待機系に自動的に切り替えを行うことでシステムダウンタイムを短縮し、ビジネス損失を最小限にするHAクラスターソフトウェアとなります。
なんで導入しているの？
HANADBに含まれる機能として、HANA System Replication（以下、HSR）があります。
HSRとは、データベースを複製する機能ですが、障害を検知したあと自動で待機系に切り替えたりする機能がないです。そのため、障害発生時に自動で切り替えられるようにLifeKeeperを導入しています。
これだけは知っておかないといけないこと（用語）
LifeKeeperを導入することで、簡単にHAクラスターを構築することができます。
なぜ簡単に構築できるかというと、SIOS社が簡単に構築できるように製品を用意しているからであり、「Application Recovery Kits（通称：ARK）」を提供しているから簡単に構築することができます。
ARKとは、HA化するアプリケーションの動作を制御するスクリプトの集まりの事です。
こちらを利用することで、短期間で導入が可能になります。
SAP以外では、以下ソフトウェアでもARKが提供されており、HA化することができます。
| カテゴリ | 対応ソフトウェア |
|---|---|
| データベース | Oracle, PostgreSQL, MySQL, Microsoft SQL Serverなど |
| データ連携/転送 | HULFT, DataSpiderなど |
| メール基盤 | Postfix, Dovecotなど |
| 監視・運用 | JP1/AJS3, Zabbixなど |
| アプリケーション基盤 | Apache, Tomcat, WebSphere MQなど |
詳細については、こちらご確認ください
導入時のTips
SIOS社が提供しているポータルサイトやリリースノートがとても見やすくわかりやすいためこちらを確認して構築作業を進める形になります。
本当によくまとまっていて、とても見やすいものになってます！
ユーザポータル
構築作業に入る前に、製品がどのような挙動になるかなどを把握するために多用しました。他にも、構築時のTipsなども転がっているため、ユーザポータルとリリースノートを行ったり来たりして情報をキャッチアップする形になります。
よく見るものは以下になります。
- システム要件・インストール要件の確認
- スプリットブレイン対策
- Quorum/Witness 構成ガイド
- フェイルオーバーの仕組み
- 〇〇Recovery Kit の処理概要
Lifekeeperリリースノート
構築時に見るドキュメントです。上記ユーザポータルよりも細かくて、詳細な手順が記載されているものになります。ある程度のLinuxやWindowsの知識があれば操作/構築ができるものになってます。
すべて目を通しますが、よく見るものは以下です。
- セットアップスクリプトの操作
- LifeKeeper User Guide
- /etc/default/LifeKeeper 構成ファイルに設定できるパラメータ一覧
- 〇〇Recovery Kit 管理ガイド
Tips
クラウド環境で設定を行う際、「/etc/default/LifeKeeper」ファイル内の『NOBCASTPING』のパラメータを変更しておかないと、リソース作成時エラーになります。通信要件を確認の上、必要に応じて変更作業を実施ください。
意識するべき設定値①（スイッチバック設定）
リソース側の設定の一部です。簡単に記載すると、障害復旧時にリソースをどうするか？の設定になります。障害を検知し、リソースがサーバAからサーバBにフェイルオーバした後の挙動で動きが変わります。
※ サーバA（稼働系）/サーバB（待機系）
- Intelligent（デフォルト設定）
- サーバAで障害復旧後、自動でリソースが戻ることはないです。 サーバBで別の障害発生するか、管理者が手動でリソースを移動するまでは、サーバBでリソースが稼働し続けます。
- Automatic
- サーバAで障害復旧後、サーバAがオンライン状態（LifeKeeperのサーバプロセスが起動している）かつ、コミュニケーションパスがALIVE状態になった後、リソースのスイッチバックが発生します。 一部のリソース（DataKeeperやHANA...etc）は、Automaticをサポートしていないため手動で戻す必要があります。
Tips
優先順位が上位のサーバから下位のサーバの場合は戻りません。
サーバAに優先順位1、サーバBに優先順位10を割り振っている場合は、B->Aに戻ります。
サーバAに優先順位10、サーバBに優先順位1を割り振っている場合は、B->Aには戻りません。
意識するべき設定値②（Shutdown Strategy）
サーバ側の設定の一部です。
簡単に記載すると、手動でサーバ停止したり再起動した際にリソースをどうするか？の設定になります。
- Do not Switchover Resources（デフォルト設定）
- サーバA側で、rebootコマンドやshutdownコマンドでサーバを停止した際、LifeKeeper側で「nofailoverフラグ」を、サーバBに作成しリソースのフェイルオーバを抑止します。ノード障害の場合は、「nofailoverフラグ」を作成しないため、フェイルオーバします。メンテナンス等があった際、意図して上記コマンドを実行した場合は、リソースが移動されないと理解してください。
- Switchover Resources
- サーバA側で、rebootコマンドやshutdownコマンドでサーバを停止した際、サーバBに「nofailoverフラグ」を作成しなくなるため、フェイルオーバが発生します。
おわり
この記事がどなたかの参考になれば幸いです。
ブログを久しぶりに書きましたが、ちゃんと自分が理解できているのか？などの再確認ができるので、やっぱり定期的にアウトプットが必要だなと再確認しました。
来年こそ、、、定期的に書ける人間になりたい(;´･ω･)