2016年7月22日金曜日

[Windows] DataKeeper Notification Icon の利用方法



こんにちは。

LifeKeeperのユーザーサイトでは、LifeKeeperによるアプリケーションの保護に活用されるアプリケーションリカバリキット(ARK)についての記事など、HAクラスターの構築に役立つ情報を掲載しています。今日は、DataKeeper Notification Iconの利用方法 をご紹介する記事のご案内です。

DataKeeper for Windows v8.3 から、DataKeeper Notification Icon が実装されました>

DataKeeper Notification Icon は、おおまかに以下三つの機能があります。

1.DataKeeper の状態をタスクバー上の通知アイコンで確認できる
2.DataKeeper GUI のショートカットとして利用できる
3.DataKeeper の各管理ツールを起動できる












記事では、今回の機能についての詳細を記載しています。
DataKeeperの新しい機能を、運用時の監視や、トラブルシューティングにご活用ください。

記事の詳細はこちら ⇒ http://lk.sios.com/?p=4696

2016年7月11日月曜日

[Linux] NFS Recovery Kit の動作概要


こんにちは。

LifeKeeperのユーザーサイトでは、LifeKeeperによるアプリケーションの保護に活用されるアプリケーションリカバリキット(ARK)についての記事など、HAクラスターの構築に役立つ情報を掲載しています。今日は、NFS リカバリーキットの動作概要をご紹介する記事のご案内です。

NFS ARKが提供する監視機能と起動処理、停止処理についてご説明します。>

対象製品
NFS Recovery Kit (LifeKeeper for Linux)

監視処理
LKCHECKINTERVAL(デフォルト120秒)の間隔で NFS リソースを監視。各処理の中のどこかで異常とみなされた場合、次回の監視時にも異常とみなされるとリソース異常とみなされ回復処理が行われます。
1)ps コマンドによりプロセスの状態を確認します。
2) /opt/LifeKeeper/lkadm/bin/pingnfs を実行して疎通を確認します。
3) /var/lib/nfs/etab より export ポイントを確認します。
4) rpc_pipefs によりマウント済みかを確認します。
5) rpcbind を利用している場合は bind マウントの状態を確認します。
1)5)の間にて処理が正常以外であればリソース異常とみなし、回復処理へ移行します。

起動処理
1) NFSのサービス提供に必要なデーモンの起動状態を確認します。
2) デーモンが停止状態であれば起動させます。
3) 対象のディレクトリを export ポイントへ追加します。

停止処理
1) 対象のディレクトリを export ポイントから外します。
2) 対象のディレクトリをバインドマウントします。

バインドマウントできなかった場合は、lockd に対して kill を行います。

記事では、監視、起動、停止処理の詳細のほか、回復処理やパラメータについての詳細を記載しています。

記事の詳細はこちら ⇒ http://lk.sios.com/?p=4680

【連携ソリューション】システナのハイブリッドBCPサービスをご紹介します

株式会社システナの沓掛です。

今回は、最短1週間で導入可能、かつ低コストにBCP事業継続計画)対策を実現する方法についてご紹介致します。

企業ITがビジネスと切っても切れない関係となった昨今、有事の際でもビジネスを止めないために、BCP対策が重要になりつつあります。

近年の大型地震の多発に加えて、首都直下地震もいつ発生してもおかしくない状況だと言われていますが、もしも実際にビジネスシステムを支えるサーバーを地震が撃した場合、果たしてビジネスを問題なく継続することが出来るでしょうか。

下図は内閣府が発行した、ビジネス継続に関するガイドラインより抜粋したものですが、BCP対策を行っていた場合と行っていなかった場合とで、被災後の業務の立ち上がりに大きな差が出ていることがお分かりになると思います。

















図:業務継続計画の実践に伴う効果の模式図
(出典:内閣府「中央省庁ガイドライン」)


BCP対策を行うにあたっての落とし穴ですが、有事の際に事業を復旧させるためには、データの復元よりも先に、まずハードウェアやソフトウェアを含めたシステム全体を再稼働させる必要があります。

しかし現状、データのバックアップは実施していても、システム全体のリカバリーまで考慮できている組織は多くありません。
場合によってはシステムの復旧に数週間もかかってしまうケースもあるのです。
また、BCP対策を万全に行っていても、平常では使用しないスタンバイサーバーの維持のために、莫大なランニングコストがかかるというケースもあります。


今回はこのような問題を一挙に解決する、弊社の『ハイブリッドBCPサービス』をご紹介致します。


◆こんなことが可能になります
『迅速なシステム自動復旧』
  →SIOS製品の"LifeKeeper"を用いることで、障害発生時には約3分(※弊社検証時)で、システムを自動復旧し、サービスを再開させることができます。

『スタンバイ系をクラウドに』
  →自社拠点がなくても、遠隔地にサーバーを設置できるため、地震などによる被災リスクを分散できます。
    難度の高いクラウド化ですが、 弊社の技術者集団がそれを実現します。

『リアルタイムにデータを複製』
  →SIOS製品の"DataKeeper"を用いることで、恒常的にデータ複製を行うことができます。
  常にアクティブ⇔スタンバイサーバー間のデータが同期されるため、障害発生直前までのデータが保証されます。

『クラウドで低コスト化』
 →クラウドでは、有事のときだけ必要な利用料金を払って、システムを稼働させることができます。
  スタンバイ系をクラウド上に構築することで、平時の不要なコストを抑えることができます。


◆圧倒的メリット
約3分でシステム自動再開(※弊社検証時)
・パッケージ化により、最短1週間で導入可能
・クラウド化により、従来(※約1千万円以上)数分の1までコスト削減


◆構成例
・サーバ/ネットワーク
Windows ServerとSQL Serverで構築された物理サーバと、クラウド(Microsoft Azure)上の仮想サーバの2台を、Internet-VPNで接続します。
(※構成は下記以外でも可能な場合がございます。ご相談ください。)
サーバ/ネットワーク

クラスタソフト
サイオステクノロジー株式会社の以下のクラスタソフトを利用します。

 - LifeKeeper for Windows
 - DataKeeper for Windows

 または、

 - LifeKeeper for Linux
 - DataKeeper for Linux

◆平常時・障害発生時の動き
・平常時
物理サーバ側のSQL Serverがアクティブ系となり、参照・更新されています。
DB上のデータはDataKeeperによって、スタンバイ系のAzure環境上にリアルタイムで複製されています。
平常時


・障害発生時

物理サーバ側で障害が発生すると、LifeKeeperの機能により、スタンバイ系のAzure環境側でSQL Serverが自動起動し、サービスが復旧・再開します。

その際、DataKeeperによって同期されていた、障害発生直前までのデータが引き継がれます。
異常時



◆まずはご相談ください!
御社の環境に合わせた提案を致します。
新規サーバー構築も、既存環境のクラウド移行も可能です。


◆リンク
・「ハイブリッドBCPサービス」弊社公式紹介ページ

・TechTarget 紹介記事
「最短1週間で導入が可能、有事でもビジネスを止めないBCP実現の“秘訣”」


◆お問い合わせ先
株式会社システナ フレームワークデザイン本部 ダイバーシティ推進室
ハイブリッドBCPサービスサポートセンター

 ※
受付時間 9:00~18:00 月~金曜日(土・日・祝祭日・当社指定定休日を除く)