はじめに
みなさんこんにちは。東日本のプリセールスの西下（にしした）です。
これまで連続で基幹系システムの障害対策として、下記の記事をご紹介致しました。
基幹系システムの障害対策のトレンドとこれからの対策（SAP・JP1・HULFT）
HULFTの障害対策のトレンドとこれから求められる対策とは？
今回はこれらをもう少し掘り下げて、なぜ多くの基幹系システムで採用されているのかについてご紹介致します。
【3分で読める】基幹系システム向けに当社ソリューションが採用されているワケ
HULFT
【3分で読める】HULFTの障害対策のトレンドとこれから求められる対策とは？
はじめに
みなさんこんにちは。東日本のプリセールスの西下（にしした）です。
前回は基幹系システムの第二弾としてSAPに続いてJP1にフォーカスして、当社の高可用性ソリューションについてお伝えいたしました。
今回は14年連続国内シェアNO.1のファイル転送ツールのHULFTにフォーカスしてこれから求められる対策についてご紹介いたします。
【3分で読める】基幹系システムの障害対策のトレンドとこれからの対策（SAP・JP1・HULFT）
はじめに
みなさんこんにちは。東日本のプリセールスの西下（にしした）です。
長かった冬もようやく春らしくなり、当社の周りでも桜が満開です。春を楽しみにされていた方も多いのではないでしょうか？
さて、今回は代表的な「基幹系システム」としてSAP・JP1・HULFTを題材にして障害対策のトレンドとこれから求められる対策についてお話させていただきます。
これらの製品に関するお問い合わせも顕著に伸びており、既に多数の実績が出ております。>>導入事例
AWS上のLifeKeeper for Linux とHULFTを連携させてみた
前回、AWS上のLifeKeeper for Linux（以降、LifeKeeperと記載）とPostgreSQLを連携させて、PostgreSQLプロセスと共有ファイルシステム上のデータベースがフェールオーバーされることを確認しました。
PostgreSQLリソースで登録したプロセスは一つでしたので、今回はHULFTを導入して複数のプロセスを登録したリソースを作成してみます。具体的な構成としては、HULFTを各インスタンスに導入し、環境設定ファイル格納ディレクトリを共有ファイルシステム領域（”/data”）配下に設定します。
この状態でLifeKeeperへHULFTリソース（三つのプロセス）を登録することでHULFTの冗長化を行いたいと思います。