早分かり！ コミュニケーションシステムの災害対策 2011/12/13 Lotus Technical Update Workshop
by user
Comments
Transcript
早分かり！ コミュニケーションシステムの災害対策 2011/12/13 Lotus Technical Update Workshop
2011/12/13 Lotus Technical Update Workshop 早分かり！ コミュニケーションシステムの災害対策 日本アイ・ビー・エム システムズ・エンジニアリング株式会社 コラボレーション・ソリューション 伊藤智子 © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 Agenda 災対システムが必要とされている理由 災対システムのアプローチ 災対システム実装における3つのポイント –データ引継ぎ • Dominoのデータ引継ぎ • Sametimeのデータ引継ぎ –被災時切替 • Domino被災時切替 • Sametime被災時切替 –災対サイト運用 • Sametime災対サイト運用 コミュニケーションシステムとしての災対構成 まとめ 2 © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 災対システムが必要とされている理由 背景 –企業内の情報システムは、停止時の業務への影響が大きいため24時間365日 の稼動が求められている –震災をきっかけに • 社内システムの災害対策の見直し • 電話が不通となり、社員の安否確認が不可となった – コミュニケーション基盤の災害対策の見直し 通常サイト 災対サイト × 3 © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 災対システムのアプローチ 決定すべき項目 ① RTO(Recovery Time Objective) • 対象業務／システムが停止してから再開するまでの時間 – インフラ起動 » ディスク切替、NW切替 » 疎通確認・単体確認の実施 – 業務切替 » サーバー間疎通確認 » ユーザー制御の開放 ② RPO(Recovery Point Objective) • 対象業務／システムが停止した時点で、どの時点までのデータを担保す るか – 災対サイトに対するデータ引継ぎの更新タイミング 4 © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 災対システムのアプローチ 決めるべき項目 ③ 業務アプリケーションのデータ保全に関する方針 • 各システムに対するデータ保全の方針と前提を確認 – 各システムの静止点の有無 – 災対サイトに対するデータ引継ぎ方法 ④ ネットワーク切替方式に関する方針 – 被災時の切替方法 – ユーザー側への影響 – RTOにも関係あり ⑤ 災対サイト運用基本方針 • 平常時運用に関する運用方針 • 業務回復運用 – ディスク追加、データ移行 5 © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 災対システム実装における3つのポイント データの データの引継ぎ 引継ぎ ②RPO/③ RPO/③データ保全 データ保全 引継ぎ対象のデータは？ その方法・更新間隔は？ ①RTO/④ RTO/④ネットワーク切替方式 ネットワーク切替方式 サーバー側変更作業は？ ユーザー側変更作業は？ 被災時切替 災対サイト 災対サイト運用 サイト運用 ⑤災対サイト 災対サイト運用基本方針 サイト運用基本方針 平常時にどういう運用が必要？ 6 © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 災対システム実装におけるポイント① データ引継ぎ データの データの引継ぎ 引継ぎ ②RPO/③ RPO/③データ保全 データ保全 引継ぎ対象のデータは？ その方法・更新間隔は？ ①RTO/④ RTO/④ネットワーク切替方式 ネットワーク切替方式 サーバー側変更作業は？ ユーザー側変更作業は？ 被災時切替 災対サイト 災対サイト運用 サイト運用 ⑤災対サイト 災対サイト運用基本方針 サイト運用基本方針 平常時にどういう運用が必要？ 7 © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 Dominoのデータ引継ぎ ～対象データ～ データ保全の方針に沿って、災対サイトに必要なデータを整理 –対象データの例 • 要件によって異なる。例えばログは引継ぎ不要とするケースも多い 対象サービス ディレクトリ 共通 対象データ ノーツDB ノーツDB (NSF/NTF) メール ノーツDB アプリ ノーツDB 他ファイル MTA メール監査 ノーツDB ディレクトリ管理（人 ノーツDB 事異動） 他ファイル 運用 ノーツDB 他ファイル 他ファイル 8 names, 2次ディレクトリ admin4, events4、カスタマイズ・テンプレート アンチウイルス S/W関連（パターンファイル、設定DB） メールDB/テンプレート アプリDB/テンプレート html等NSFに格納されないもの（Webアプリで必要な場合） 特に不要 ジャーナルデータ ユーザー/グループ管理DB（カスタムアプリ使用の場合） 認証者ID Log.nsf ログ、各種運用スクリプト等 notes.ini、サーバーID （本番と同一サーバー名で起動させる場合） © 2011 IBM Corporation ･･･ユーザーデータ 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 Dominoのデータ引継ぎ ～データ同期方法～ ノーツDB（NSF、NTF）ファイルの同期方法の主な選択肢 –Dominoクラスタ構成を用いるのが主流 ①Dominoクラスタ ②定期複製 …事例多数 本番サイト 災対サイト …事例多数 本番サイト 災対サイト 定期複製 クラスタ複製 クラスタ複製 ③テープ搬送 災対サイト 本番サイト 搬送 9 ④ストレージ機能 …事例あり 本番サイト 災対サイト （Domino停止状態 Domino停止状態の 停止状態の） スナップを スナップを同期 © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 Dominoのデータ引継ぎ ～データ同期方法～ ノーツDB同期方法でDominoクラスタが主流となっている背景① –Dominoクラスタ方式が最も直近のデータを引き継げる 同期方法 RPO比較 ①Dominoクラスタ ◎ 基本的に即時反映 ※更新量が多い場合などクラスタ複製で即時反映されない場合は定期複製間隔 となる。 ②定期複製 ○ 設定により数分～数時間 ③テープ搬送 × 搬送リードタイムのため数日 ④ストレージ機能 △ Dominoの場合は1日程度 ※ストレージ機能による差分同期は、ディスクブロック単位で更新を反映する。 一方、ノーツDBはCompactによってブロックが詰め直されるため、フルコピーに 近い差分量となってしまう場合がある。 <Compact前> <Compact後> そのため、同期の所要時間が長くなり、RPOが長くなる。 10 © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 Dominoのデータ引継ぎ ～データ同期方法～ ノーツDB同期方法でDominoクラスタが主流となっている背景② –N/W帯域が昔より確保しやすくなっている （参考）WANクラスタFAQ –WANクラスタの考慮事項は？ •N/W帯域が十分であれば、特にありません。 –WANクラスタで必要な帯域幅の見積方法は？ •方法1：統計情報を参考に算出 –NET.<portname>.BytesReceived –NET.<portname>.BytesSent ※<portname>は、サーバー文書>ポートタブ>ポート の値（例：TCPIP） •方法2：目安として1000ユーザーに対して1.5Mbps Redbooks『Domino 7 Performance Tuning Best Practices to Get the Most Out of Your Domino Infrastructure』6.1.4章参照 http://www.redbooks.ibm.com/abstracts/redp4182.html 11 © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 Sametimeのデータ引継ぎ ～対象データ～ 対象サービス –コミュニティーサービス（チャット・在席確認） –ミーティングサービス（オンラインミーティング） 各サービスのデータ保管先 コミュニティーサービス ノーツDBを使用 8.5 コネクト クライアント コミュニティー サーバー VP Domino ミーティングサービス DB2を使用 vpuserinfo.nsf ミーティング サーバー Web ブラウザー DB サーバー HTTP/HTTPS WAS 12 © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 Sametimeのデータ引継ぎ ～対象データ～ データ保全の方針に沿って、災対サイトに必要なデータを整理 – 対象データの例 • 要件によって異なる。例えばログは引継ぎ不要とするケースが多い 対象サービス 対象データ ディレクトリーサー ビス LDAPディレクトリ情 報 （使用するLDAPサー バーによる） ユーザー情報格納 コミュニティーサー ビス ユーザー使用デー タ（ノーツDB） vpuserinfo.nsf 「コンタクトリスト」情報、「プライバ シーリスト」情報を格納 サーバーデータ （ノーツDB） names.nsf サーバー情報、Sametime管理者情 報の格納 stconfing.nsf（*1） Sametime のシステム管理ツールで 設定した構成パラメータを格納 server.id （*2） notes.ini（*2） sametime.ini（*1）など サーバー設定ファイル その他 13 役割 ログファイル チャットログ （*1）基本的に引継ぎ不可 （*2）本番と同一サーバー名で起動させる場合 チャット内容の取得 ･･･ユーザーデータ © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 Sametimeのデータ引継ぎ ～対象データ～ データ保全の方針に沿って、災対サイトに必要なデータを整理 – 対象データの例 • 要件によって異なる。例えばMTGデータは引継ぎ不要とするケースも多い 対象サービス 対象データ ミーティングサービ ス 新MTG用データ DB2 ミーティングで使用する資料、グ ループチャットなど格納 クラシックMTG用 データ （ノーツDB） stconf.nsf（*1） ミーティング予約文書、ミーティング で使用する資料、グループチャット など格納 サーバーデータ DB2 SSCを利用して設定する各 Sametimeサーバーに関するデータ を格納 設定ファイル XMLファイルなど サーバー設定ファイル Sametime System Console（SSC） （*1）本番と同一サーバー名で起動させる場合 14 役割 ･･･ユーザーデータ © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 Sametimeのデータ引継ぎ ～データ同期方法～ ディレクトリサービスに関して –使用するLDAPディレクトリに応じて、引き継ぐ仕組みが必要 コミュニティサービスにおける主な選択肢 対象サービス 対象データ 同期方法 RPO比較 コミュニティサービス ノーツDB ①Dominoクラスタ ◎ 基本的に即時反映（Dominoと共 通） ②通常複製 ○ 設定により、数分～数時間 （Dominoと共通） ノーツDB以外 （チャットログ） 15 ③OSコピー ④ストレージコピー △ ① OSコピー ②ストレージコピー △ 1日程度（Dominoと共通） 1日程度 © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 コミュニティーサービスのデータ同期 全体構成 コミュニティーサービスの同期方法 –Dominoクラスタ構成の利用 通常サイト 災対サイト Sametimeクラスタ コミュニティー サーバー#1 サーバー#1 names .nsf vpuserinfo .nsf Dominoクラスタ Dominoクラスタによる クラスタによる 即時複製 チャットログ コミュニティー サーバー#2 サーバー#2 names .nsf vpuserinfo .nsf チャットログ バックアップ時に合わせて ファイル転送など 16 © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 Sametimeのデータ引継ぎ ～データ同期方法～ ミーティングサービスにおける主な選択肢 対象サービス 対象データ 同期方法 RPO クラシックミーティング ノーツDB（*1） ①通常複製 ○ 設定により、数分～数時間 （Dominoと共通） ②ストレージコピー △ 1日程度（Dominoと共通） 新ミーティングサービス DB2 ①HADR機能 (*2) ◎ 同期/非同期でコピー可能 ②ストレージコピー △ 1日程度（Dominoと共通） ③オンラインバックアップ /リストア △ 設定により、数分～数時間 （*1）本番と同一サーバー名で起動させる場合 （*2）DB2 HADR(High Availability Disaster Recovery) http://www.ibm.com/software/jp/data/db2/v9/advantage/hadr.html 17 © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 Sametimeのデータ引継ぎ ～データ同期方法～ クラシックミーティングサービスの同期方法 –ノーツDB • 通常の複製時には注意点あり –注意点 • クラシックミーティングのURLはサーバー名が記入されるため、同名での サーバー起動が必要 18 © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 災対システム実装におけるポイント② 被災時切替 データの データの引継ぎ 引継ぎ ②RPO/③ RPO/③データ保全 データ保全 引継ぎ対象のデータは？ その方法・更新間隔は？ ①RTO/④ RTO/④ネットワーク切替方式 ネットワーク切替方式 サーバー側変更作業は？ ユーザー側変更作業は？ 被災時切替 災対サイト 災対サイト運用 サイト運用 ⑤災対サイト 災対サイト運用基本方針 サイト運用基本方針 平常時にどういう運用が必要？ 19 © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 Domino被災時切替 ～ユーザー接続切替方法～ Notesクライアントの接続切替方法：主な選択肢 –Dominoクラスタを用いるのが主流 N/W切替 Dominoクラスタ 本番サイト 災対サイト 本番サイト 災対サイト 本番と同一 サーバー名で起動 × クラスタ フェイルオーバー NAT変換 切替 手順書 ただし災対サイトの 名前解決できることが重要 20 ユーザー作業：なし ユーザー作業：なし RTO：◎ RTO：△ © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 Domino被災時切替 ～ユーザー接続切替方法～ Notesクライアントの接続切替方法： N/W切替方式 –Dominoサーバー • サーバーID・Notes.iniを置き換えて本番と同一サーバー名で起動 – そのためアプリケーションがクラスタ対応でなくてもよい –N/W • NAT変換で、本番サーバーへの接続を災対サーバーに振る – 以下のことから、DNSだけでは対応できない • NotesクライアントがDominoサーバーへの接続パスを決定する順序： – 個人アドレス帳/連絡帳の接続文書 – ロケーション文書のキャッシュ – ホームサーバーに問い合わせ – Dominoサーバーの共通名をホスト名として、OSに対して名前解決を要求 （→hosts, DNS） 21 © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 Domino被災時切替 ～ユーザー接続切替方法～ Webブラウザの接続切替方法： –N/Wでの切替が一般的 N/W（DNS等） DNS利用時の注意点 本番サイト 災対サイト DNS変更 •DNSサーバー自体の災害対策が必要 •DNSキャッシュの問題 （サーバー側/ユーザー側） •場合によってはDNSをクリアする コマンド実行（flushdns） ユーザー作業：なし RTO: ○ 22 © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 Domino構成Tips：接続制御関連の設定 Server_Restricted=2 –ユーザー/サーバーからの接続ができないようにする設定 • 管理者には適用されない – サーバー文書のセキュリティタブの「管理者」権限 –自分から他サーバーへの接続（メール、複製等）は可能 –クライアントからの複製は可能 • Notes/Domino8.5.2FP3/8.5.3以降これ も制限可能で、「=4」に設定すると、管 理者以外は複製もできない。 詳細は以下のKnowledge Baseを参照 ○ =2 Restricted × ×○ 「=4」ならこれ も× – （参考）NOTES.INI パラメータ Server_Restricted について http://www.ibm.com/support/docview.wss?uid=swg21465299 – （参考）SERVER_RESTRICTED パラメータを設定した後も一般ユーザーがサーバーに接続できる 場合がある http://www.ibm.com/support/docview.wss?uid=swg21464970 23 © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 Domino構成Tips：接続制御関連の設定 Server_Availability_Threshold=100 –サーバーをBUSYステータスにする –他のクラスタメンバーが接続不可の場合はBUSYでも接続される Server_Availability_Thresh old=100 old=100 クラスタ Available BUSY Server_Availability_Thresh old=100 old=100 × クラスタ こちらに接続 できない場合は… BUSY …Busyでも接続 サーバー文書「サーバーへのアクセス可」（セキュリティタブ） –指定されたユーザー/サーバー以外の接続を拒否する 24 © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 Domino構成例：災対サーバーは被災時のみアクセス 本番サイトに2台・災対サイトに1台の３サーバークラスタ構成 1. 正常時は、本番用サーバーを使用 2. 本番用サーバー障害時のみ、障害時用サーバーを使用 3. 本番サイト被災時のみ、災対用サーバーを使用 Server_Availability_Thresholdだけでは実現できない 通常時 障害時 本番サイト 災対サイト 災対時 本番サイト Server_Availability_Th reshold=100 クラスタ 災対サイト Server_Availability_Th reshold=100 × クラスタ どちらにアクセス どちらにアクセスするか アクセスするか は制御できない 制御できない 25 災対サイト 本番サイト Server_Availability_Th reshold=100 × クラスタ © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 Domino構成例：災対サーバーは被災時のみアクセス（続き） Server_Availability_Threshold だけでは実現できない 災対サーバーには Server_Restricted を設定 –災対切替作業において解除 通常時 障害時 災対サイト 本番サイト Server_Availability_Th reshold=100 クラスタ 26 Server_Restr icted=2 災対時 災対サイト 本番サイト Server_Availability_Th reshold=100 × Server_Restr icted=2 クラスタ 災対サイト 本番サイト × Server_Restr icted=0 0 クラスタ © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 （参考）Domino構成例：災対サーバーを障害対応にも利用 「Server_Availability_Threshold」で可能 –災対切替において、接続のための設定変更は不要 通常時 障害時 本番サイト 災対サイト 本番サイト Server_Availability_Th reshold=100 クラスタ 災対時 災対サイト Server_Availability_Th reshold=100 × クラスタ 災対サイト × Server_Availability_Th reshold=100 クラスタ クラスタ フェイル オーバー 27 本番サイト クラスタ フェイル オーバー © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 Sametime被災時切替 ～ユーザー接続切替方法～ ユーザー接続切替方法 –クライアント側で自動的に切替えることができない • Sametimeコネクトクライアント • Notes IM • Webクライアント • ミーティングルームクライアント –自動的に切り替えるためには、N/W側での対応が必要 • DNS切替 28 © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 Sametime被災時切替 ～ユーザー接続切替方法～ ユーザー接続切替方法 29 切替方法 ①N/W（DNS）切替 ②手動切替 ③同名サーバーの起動 DNS切替 ユーザー作業 DNSレコードの書き換えが発生する ため，場合によっては明示的にDNS 情報の再取得(例:dnsflushコマンド)を 実施 サーバー名書き換え作 業発生 特になし RTO ○ △ △ DNSキャッシュの問題に注意 ユーザー側の作業時間 による サーバー起動のための作業 が発生 © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 Sametime被災時切替 ～ユーザー接続切替方法～ ユーザー接続切替方法 –コミュニティーサービス • DNS切替 • 同名サーバーの起動 – 既存Sametimeサーバーが存在する場合 –注意点 • DNSキャッシュの問題（前述のDominoと共通） 30 © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 Sametime被災時切替 ～ユーザー接続切替方法～ ユーザー接続切替方法 –ミーティングサービス • 旧バージョンでは手動切替が主流 • Sametime 8.5.x以降では、DNSを使った自動切替が主流 –注意点 • 手動切替の場合 – 旧バージョン：ユーザー側がスムーズに切替作業が実施できるように、ブラウザ のブックマーク機能の利用など運用での対応が必要 – Sametime 8.5.x以降 » コネクトクライアント上にミーティングルームの一覧表示機能あり。手動切替の場合、 クライアント側での設定変更が発生 31 © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 Sametime構成例①：コールドスタンバイ構成 #1 ミーティングは対象外 通常サイト 災対サイト メール サーバー#1 サーバー#1 vpuserinfo .nsf メール サーバー#2 サーバー#2 他サーバー経由 サーバー経由の 経由の複製 vpuserinfo .nsf コミュニティー サーバー#1 サーバー#1 names .nsf 32 vpuserinfo .nsf 接続切替方法：DNS切替 ユーザー側変更作業なし コミュニティー サーバー#1 サーバー#1 names .nsf OSコピー OSコピー vpuserinfo .nsf © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 Sametime構成例②：コールドスタンバイ構成 #2 通常時構成 通常サイト 災対サイト コミュニティー サーバー#1 サーバー#1 Domino サーバー#2 サーバー#2 Sametime関連の サービスは停止 ホットスタンバイ構成 通常複製 names .nsf vpuserinfo .nsf names .nsf vpuserinfo .nsf 災害時構成 × コミュニティー サーバー#1 サーバー#1 names .nsf 33 vpuserinfo .nsf 同名サーバー 同名サーバーとして サーバーとして 起動 notes.ini server.id コミュニティー サーバー#1 サーバー#1 names .nsf vpuserinfo .nsf © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 災対システム実装におけるポイント③ 災対サイト運用 データの データの引継ぎ 引継ぎ ②RPO/③ RPO/③データ保全 データ保全 引継ぎ対象のデータは？ その方法・更新間隔は？ ①RTO/④ RTO/④ネットワーク切替方式 ネットワーク切替方式 サーバー側変更作業は？ ユーザー側変更作業は？ 被災時切替 災対サイト 災対サイト運用 サイト運用 ⑤災対サイト 災対サイト運用基本方針 サイト運用基本方針 平常時にどういう運用が必要？ 34 © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 Sametime災対サイト運用 Sametimeサーバー通常時運用 –同期が出来ない構成ファイルについては、運用でカバーする必要あり • SSCを利用したサーバー構成に関するデータの保管先 – DB2、xmlファイル » どのファイルへの書き込みがあるか非公開、ファイル単位でのコピー不可 – Sametime設定データベース（stconfig.nsf） » IPアドレスなどの設定値が含まれているため、複製不可 引き継げないデータに関しては、基本的に各サイトでの運用管理が必要 ただしSSCからの設定変更（ポリシーの変更など）は、頻繁には発生しない 35 © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 コミュニケーションシステムとしての災対構成 IBM社内事例 –社員の安否確認 • 震災直後は、電話が不通に。移動も困難に。 –災害対策本部の設置 • SametimeのWeb会議システムを利用しての遠隔地とのコミュニケーション 実施 –震災後の在宅勤務システム • 連絡用ツールとしてSametime活用 36 © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 コミュニケーションシステムとしての災対構成 IBM社内事例 –震災後にコミュニケーションツールに対して必要とされた要素 • リアルタイム性 • 双方向性 震災直後、コミュニケーションツールとしてもっとも活躍したものは、 IBM Sametimeのようなリアルタイム・コラボレーションツール 災害対策が必要なシステムの見直し 災害時にすぐ使用できるように、 リアルタイム・コラボレーションツールを普段から活用 37 © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 コミュニケーションシステムとしての災対構成 災害対策システムとしてのクラウド利用の可能性 –本番システムとの同時被災の可能性が低くなる • 災害対策としてデータの引継ぎについては考慮が必要 –規模によってはオンプレミスの方が安価 • 普段は停止しておき災害時にのみ使用、など 38 © 2011 IBM Corporation 早分かり 早分かり！ かり！コミュニケーションシステムの コミュニケーションシステムの災害対策 まとめ 災害対策システム構成にあたり どのシステムの災害対策構成が必要かを見極め システムに対して、RTO/RPOの視点で捉えた構成を選択 注意点を踏まえての設計・運用を実施 コミュニケーションシステムの災害対策により いざという時の、コミュニケーションの継続が可能に 39 © 2011 IBM Corporation