1. ホーム
  2. ユニリタのナレッジ
  3. UNIRITAマガジン一覧
  4. 【2013年12月号】BSPマガジン

【2013年12月号】BSPマガジン

お客様と探る!海外視察レポート

2013年11月3日から11月8日まで、クラウド活用技術を積極的に事業に取り込み、業績を伸ばしている優良企業やクラウド技術開発企業を訪問。同時に米国サンタクララで開催されたクラウドEXPO2013も視察し、クラウド技術の事業活用に関する最新動向や全体像を調査してきました。その概要をレポートします。

レポートダイジェスト1~海外視察概況

ハイブリッドクラウドの活用が主流

エンタープライズ領域のクラウド活用は、ハイブリッドクラウド環境が前提となりつつあります。企業におけるITリソースは、その活用効果の最大化が強く求められます。パブリッククラウド、プライベートクラウド、さらに既存のオンプレミス環境がそれぞれ最適な業務を担うというハイブリッドな環境は、一方で、運用の複雑化をもたらします。米国では既にハイブリッドクラウド環境における開発上、運用上の問題を見据えた技術開発が活発に行われていました。訪問した企業では、そういった運用面でのニーズに応える形で様々なアプローチを展開し、サービスコンセプトを明確に提示していました。

ビッグデータ分析による予測検知サービス

ビッグデータ分析による予測保守サービスが実用化されつつあります。ビッグデータの収集と分析に関する技術が体系化され、一部の企業では、予測検知サービスとして提供を始めています。訪問企業のひとつ、Sumo Logicは、ログ解析サービスをクラウド展開する企業ですが、様々な顧客のサーバから収集したログを基にパターン解析し、次の異常を予測して知らせる仕組みを提供しています。

また、General Electric Company(以下GE)では、各部品のセンシングデータを収集・分析し、部品のメンテナンス時にそれらのログを解析することでメンテナンスを効率化しています。さらに、部品がいつ壊れるかを事前に予測し、故障前にメンテナンスを行うことで定期メンテナンスを不要にし、コスト削減を実現するという構想も進めています。

センシングデータ:センサーを利用して物理量や音・光・圧力・温度などを計測・判別したデータ

クラウドAPIのトレンド

 クラウドサービスを展開するにあたり、OpenStackベースのサービスが活発化しています。クラウドEXPOの出展企業においては、ハイブリッドクラウドを前提としたサービスや製品インターフェースは、OpenStack対応を謳ったものが多く占めていました。クラウドOSにおけるメジャーなOSSとしては、OpenStack、CloudStack、Eucalyptusなどが著名ですが、米国NASAが主導で行っていることも起因し、OpenStackが急速にシェアを拡大しています。IBMやHP、AT&Tなどの各社はOpenStack開発に技術者を配して積極的に携わることで自社サービスに組み込みやすくし、主導権を握ろうとしているようです。

OpenStack:クラウド基盤を構築するオープンソースソフトウェア。IaaSやストレージサービスを提供するための仮想マシンやストレージ、ネットワークの管理機能などを提供

既存環境とクラウドサービスの連携

既存のインフラやアプリケーションに大きな変化を加えず、アプリケーションをクラウドインフラへ移行しつつ、既存の環境と連携させる技術開発も積極的に進められています。自社のオンプレミス環境をスケーラブルで高可用なクラウドインフラへ移行したいという強いニーズがある一方、既存環境の資産との密接な連携も維持することが求められています。既存環境とクラウドサービスとの連携、クラウドへの部分的移行といった「つなぐ」ための取り組みが、訪問各社ならびにクラウドEXPO出展企業各社の共通コンセプトでした。

レポートダイジェスト2~訪問企業ピックアップ

ビッグデータ分析の予防保守への適用

~Sumo Logic~
 ログ収集・分析をクラウドサービスとしてグローバルに展開、ここ一年で200社以上の導入実績があります。日本の顧客における実績もあり、システムのログ収集・解析を行う同社のクラウドサービス「Elastic Log Processing」は、ログデータを圧縮する独自技術「Log Reduce」による高速解析により、複数の企業のログ解析結果から異常検知のパターンを特定し、アラート設定を標準化する取り組みを進めています。

~GE~
「世界がいま本当に必要としているものを創る」というスローガンのもと、エネルギー問題や、医療問題などの世界的に困難な課題を解決することで社会貢献を果たすと掲げています。同社CEOが推進する「Industrial Internet」の取り組みは、エンジンや風力発電機など同社が提供する部品にセンサーを設置し、日々の膨大なセンシングデータからリアルタイムに部品の状態や性能を測定するというものです。この蓄積したセンシングデータをビッグデータとして分析し、いつ故障が発生するかを予測して、予期しない故障やダウンタイムを未然に防止するソリューションの展開を始めています。この取り組みによる1%の効率化は、世界の産業界にとって15年で3兆円の節約ができると言われています。

マルチクラウンド環境へのアプリケーション配布

~GigaSpaces~
インメモリコンピューティング、分散コンピューティングの分野で活躍する企業で、パブリックとプライベートクラウドだけでなく、物理的なハードウェアを含むさまざまな環境へ、自動的にアプリケーションを配布するOSSのミドルウェアを提供しています。

金融、流通、社会インフラなど幅広い事例があり、同社のクラウドサービス「Cloudify」は、世界最大級の総合金融企業であるバンク・オブ・アメリカなどに採用されています。

レポートダイジェスト3~視察企業にみるクラウド技術の方向性

今回、訪問した企業6社の製品は、いずれも米国の主要IT紙(Information Week、Network Worldなど)で「注目されるクラウド管理ツール」として紹介されています。各社の実績や技術体系を見た上で、各社の製品やサービスが市場で注目される理由として、以下のキーワードが関係しているようです。

(1)異なるインフラ環境を横断して、移行・連携・統合管理を実現する
(2)インフラのクラウド化を活かして、ビッグデータを積極的に活用する
(3)クラウド基盤技術の普及にOSSを活用、特にOpenStackを採用する

今回の視察で入手した市場動向や技術情報は、BSPのクラウドサービス「Be.Cloud」へ活かして随時展開する予定です。BSPは、今後もお客様のクラウド導入や導入後の運用におけるさまざまな課題を解決し、クラウド時代におけるITシステム運用の新しい形を提案してまいります。

●取材先イベント名称
・Cloud EXPO 2013 @Santa Clara

●視察訪問6社
・Sumo Logic
・Clustrix
・GigaSpaces
・Cloud Cruiser
・GE
・Mulesoft

BSPサポート通信

【自動化】サーバ版A-AUTO『A-AUTOシステム 監視ファイルのメンテナンス方法』

サーバ版A-AUTO V7.2.2以降に新機能として追加された、「長時間走行ネットワーク監視機能」についてご紹介します。

ファイルの種類 ISAMファイル名
ネットワーク情報監視ファイル aux_esvnfile_d、aux_esvnfile_i
ジョブ情報監視ファイル aux_esvjfile_d、aux_esvjfile_i

※Windowsの場合は、それぞれのファイルの接頭が“aux_”ではなく“auw_”となります。

これらのファイルは、最終スケジュール(sfinユーティリティ)を実行するたびに運用日分のネットワークの監視情報が追加されるため、毎日監視情報が増え続けてファイルシステムを逼迫する要因となります。また、ISAMファイル形式には、ファイルの最大サイズが2GBという制約があります。2GBのサイズを超えると正しく情報を書き込むことが出来なくなり、監視ができなくなります。そのため、esvdelユーティリティを実行して、不要になった監視情報を削除する必要があります。

esvdelユーティリティは、上記の監視ファイルからパラメータに指定された期間のレコードを取り出し、ファイルを作成し直すユーティリティです。

使用例1(ユーティリティの実行日から起算して7日間分のみの監視情報を保持する場合)
“esvdel -k 7”

※パラメータの指定方法の詳細については、オペレーションガイド(V620以前の場合はユーザーズガイド)をご参照ください。

esvdelユーティリティによる監視ファイルのメンテナンスは定期的に行うことが望ましいため、月に1回程度の頻度で実行することを推奨します。

【注意点】
・esvdelユーティリティを実行すると、バックアップファイルとテンポラリファイルが作成されるため、ディスク容量に空きがあることを確認の上、実行してください。
(V700以前の場合):元の監視ファイルのサイズと同等の空き容量が必要になります。
(V710以降の場合):元の監視ファイルのサイズの2倍以上の空き容量が必要になります。
・esvdelユーティリティの実行時には監視ファイルに排他制御が掛かるため、パフォーマンスの観点からネットワークの起動・終了が頻繁に発生する時間帯を避けて実行するようにしてください。

【帳票】BSP-RM 「システム停止時の注意事項」

「BSP-RM」を停止する場合、以下の注意事項を参考に対応してください。

【UNIX/Linuxの場合】

停止手順に従いプロセスを停止、またはコマンドを発行して「BSP-RM」を終了する。

【Windowsの場合】

「BSP-RM」関連サービスの停止を実施する。

※詳細な手順は「オペレーションガイド(サーバ編)」の1.2章終了手順をご覧ください。

 誤って正規の手順を踏まずに「BSP-RM」を停止してしまった場合(「BSP-RM」のプロセスを停止せずにサーバの電源を落とした等)、以下の対処を実施してください。

【対処1~UNIX/Linuxの場合~】

(1)残存ファイルの存在確認、削除を実施します。

#ls -al /tmp/BSP/.abas*
#rm /tmp/BSP/.abas*
#ls -al ${BSPRM_ROOT}/temp/.bspfifo*
#rm ${BSPRM_ROOT}/temp/.bspfifo*
#ls -al /tmp/.s.PGSQL.xxxx
#rm ${PGHOME}/data/postmaster.pid

(2)「BSP-RM」プロセスの起動をお試しください。

【対処1~Windowsの場合~】

「BSP-RM」関連サービスの起動をお試しください。

【対処2格納処理リカバリ】

「BSP-RM」クライアントよりレポートインデックス(RI)の「格納ステータス」をご確認ください。「BSP-RM」への格納中レポートがあった場合、格納ステータスが「異常終了」となったレポートが存在します。格納ステータスが「異常終了」のレポートを再度格納してください。

【対処3出力処理、配信処理のリカバリ】

「BSP-RM」クライアントよりレポートインデックス(RI)の「出力ステータス」をご確認ください。「BSP-RM」から出力中、配信中のレポートがあった場合、出力ステータスが「未出力」「異常終了」となったレポートが存在します。出力ステータスが「未出力」「異常終了」のレポートを再出力、再配信してください。

【ITサービスマネジメント】LMIS、LMIS on cloud 「計画停止時の注意点」

「LMIS」(オンプレミス版)

「LMIS」は、社内ネットワーク上に設置したサーバ内にシステムを構築します。そのため、設備点検による停電や、ネットワークの工事による計画停止時、システムが利用出来なくなります。

これに備えて、システム停止中のインシデント対応方法やシステム再開時のインシデント登録方法を担当者に事前通知しておく必要があります。発生したインシデントは、システム再開後、各担当者の手動登録となりますが、発生する数が多いと想定される場合、Microsoft SQL Serverへの一括登録方法の確立など事前準備が必要になります。

また、監視ツールと「LMIS」の連携を実施している場合、計画停止時のイベントを破棄する、またはアラートを表示させない、または「LMIS」に取り込まないなどの方針を決め、計画停止にあわせて実施してください。

システムの計画停止、起動の手順は以下の通りです。

【システム停止時】

以下の順番でサービスを停止してください。
①Apache Tomcat
②BMC Remedy Action Request System Server
③BMC Remedy Email Engine
④Microsoft SQL Server

【システム起動時】

システム停止時と逆の順番にてサービスを起動してください。
※BMC Remedy Action Request System Serverのサービスは、Microsoft SQL Serverのサービスが正常に起動している事を必ず確認してから、起動してください。稼働していない場合、システムが正常に起動しません。

「LMIS on cloud」

「LMIS on cloud」では、株式会社セールスフォース・ドットコム(以下、セールスフォース・ドットコム社)が構築したプラットフォーム上にサービスを構築しており、システム停止についてはセールスフォース・ドットコム社の運用に依存します。

稼働率は2013年現在、予定稼動時間(24時間365日)に対して99.9%以上を達成しています。

セールスフォース・ドットコム社ではシステムをすべて多重化しているため、基本的にはバージョンアップ以外のメンテナンス時にサービスが停止することはありません。

やむをえず停止を伴うメンテナンスを実施する場合は、緊急のメンテナンスを除き、実施10日前に以下のサイトに情報が公開されるとともに、サービスログイン時にすべてのユーザへ通知が行われます。

http://trust.salesforce.com/trust/jp/maintenance/

サービス停止に関する時間帯については、日曜日の深夜といった日本のビジネス時間外に設定され、日常業務への支障を最小限に抑えています。

【その他】メインフレーム停止時の連携版オープン側A-AUTOの対応について

メインフレーム(以下MF)が停止された場合の、連携版オープン側「A-AUTO」の対応について紹介します。

MF側の「A-LOCAL」を停止して、オープン側のarmtを停止しない場合、armtはARMT_TIMERINTERVALパラメータに指定した間隔(デフォルト10秒)で接続の要求を繰り返します。「A-LOCAL」が再起動されたときに自動的に接続され、netendfileに蓄積された(切断中に終了した)ネットワーク情報が送信されます。その際、以下の事象が発生する場合があります。

(事象1)複数もしくは1つのオープン側「A-AUTO」と接続している場合、いずれかのオープン側「A-AUTO」との接続が完了しない場合がある。
(事象2)MF停止中にオープン側で大量のネットワークが終了した場合、MF再起動時に「A-AUTO」モニタから’ATM031W INSUFFICIENT CMDQ UNIT FOR NETWK’メッセージが出力され、終了済みネットワークに対するキャンセル・フリーオン・コマンドが処理されない場合がある。

各事象に対する障害対応PTFの適用を推奨しますが、以下のオペレーションで暫定対応することができます。

(1)MF側「A-LOCAL」停止時には、全てのオープン側armtも停止する。ただし、オープン側「A-AUTO」モニタを停止する必要はありませんので、オープン側の業務処理を続行することが可能です。

(2)「A-LOCAL」起動後、オープン側armtを1つ起動する。「A-LOCAL」が、接続完了メッセージ‘APL252I SESSION FROM (AUTOxx) IS SUCCESSFULLY OPENED’表示後、オープン側に終了済みネットワークが蓄積されている場合は、全てのネットワークに対して「A-LOCAL」が終了メッセージを受信して‘ALC009I NETWORK nnnnnnnn/yyyymmdd ENDED RC=x TIME=hh:mm:ss AT AUTOxx’メッセージを表示するのを確認する。

(3)(2)を繰り返して、順次オープン側armtを起動する。

年末年始、GW連休などで長期間MFを停止した場合

前述のネットワーク情報のnetendfileへの蓄積に加えて、オープン側「A-AUTO」のネットワーク・キューに他ノードの先行ネットワークを持つネットワークが残っている場合、モニタはTMR_TIMER_INTERVAL(デフォルト30秒)x40の間隔で他ノードの先行に対する問合せメッセージをnetendfileに書き込みます。MF再起動後、「A-LOCAL」との接続後、armtはnetendfileに大量に蓄積されたメッセージを一度に「A-LOCAL」に送信しようとします。その際下記の事象が発生する場合があります。

(事象3)オープン側armtが大量に蓄積されたメッセージを送信しきれずにハングアップしたり、内部メモリ・キューがオーバーフローして情報がロストしたりする場合がある。

事象3を回避するためには、長期間MFを停止する場合、オープン側「A-AUTO」も停止してください。

※「A-AUTO」メインフレーム版FAQ「メインフレームを停止する場合、メインフレーム連携のオープン側『A-AUTO』も停止する必要がありますか」より抜粋

まずはお気軽にお問い合わせください。

どのサービスが一番適しているの?課題がまだまとまっていない。。。 こういう事例はある? 見積もりだけでもいい?

  • 東京本社 03-5463-6381
  • 名古屋事業部 052-561-6808
  • 大阪事業部 06-6245-4595
  • 福岡事業部 092-437-3200

※受付時間:平日9:00~17:30

お問い合わせフォーム