特集・ブログ

全て

2020年12月25日

「壊れにくく、処理速度が落ちない」IBM FlashSystem の特長とラインナップを徹底解説

数年前からその高速性が注目を集めていたオールフラッシュストレージですが、ここにきて大きく市場が伸びています。 以前は、特に高速な処理が必要なデータベースなどの特定用途に導入されるケースが多く見られましたが、SSD の低価格化とともに、より汎用的な用途で導入されるケースが増加。従来の HDDストレージとポジションが逆転し、「基本的にはオールフラッシュストレージを検討し、バックアップなど容量が大きく、アクセス頻度が少ないものに HDD を利用する」スタイルが一般的になりつつあります。 様々なベンダーがオールフラッシュストレージを展開するなかで、屈指の高いシェアと高い評価を誇るのが「IBM FlashSystem」です。 他製品との比較において、レイテンシ―が低く高速であることが最大の利点。加えて、データ圧縮などによるストレージ基盤の効率化やマルチベンダー・マルチクラウドへの対応…など、魅力の多い IBM FlashSystem について、その特長や活用シーンをまとめて解説します。   IBM FlashSystem の2大特長を支える独自技術 IBM FlashSystem の魅力は、大きく「壊れにくいこと」「性能が落ちないこと」の2つ。これらを主にハードウェアベースでの設計・制御によって実現していることが特長と言えます。 そしてその中核を担うのが、IBM が特許を持つ高速かつ長寿命のフラッシュモジュール「FlashCore Module(以下、FCM)」です。 FCM は、モジュール単位ではなく1つのモジュール内に搭載されているチップ単位で RAID を組むため、チップが障害を起こしただけではモジュール交換の必要なく、高可用性(=壊れにくい)につながります。さらに FCM は、ハードウェアベースでのデータ圧縮を実現しており、コントローラに負荷をかけずに処理速度を維持したままデータ量を削減できます。 設計面でも様々な配慮がされています。 例えば、フラッシュストレージでは書き込み処理のための余剰領域が必要ですが、一般的には全体の数%程度にとどまるところ、IBM FlashSystem では全体の20%強をシステムで自動的に確保します。これにより、余剰領域不足のために突然性能が大きく下がる「Write Cliff(書き込み処理性能ダウンの崖)」を回避し、常に一定以上の性能が担保されます。 ベンチマークなどの検証環境だけでなく、実際の利用シーンの中でもしっかりスピードが出るような設計となっています。 オールフラッシュストレージは、製品ごとの「クセ」が強いものが多く、それぞれの特性を理解してチューニングしなければ「思ったような性能を得られない」「極端に遅くなってしまう」といったことも少なくありません。 IBM FlashSystem は、その特性をあまり意識しなくても「普通に使えば、一定以上の性能が出る」ことが大きなアドバンテージであり、使いやすい製品に仕上がっていると言えるでしょう。   エントリーからハイエンドまで、 幅広い要件に対応できるラインナップ IBM FlashSystem のラインナップは、エントリーモデル(5010/5030/5100)、ミッドレンジモデル(5100/7200)、ハイエンドモデル(9200)と幅広く展開され、様々な要件に対応できます。上述の FCM を選択できるのは5100以上のモデルとなりますが、そのほかはデータ圧縮や重複排除など必要な機能と、性能要件をベースに選定すれば問題ありません。 すべてのモデルが同じソフトウェア「IBM Spectrum Virtualize」をベースに動作するため、互換性が高く、移行・拡張時もスムーズです。 また、オールフラッシュストレージでは SSD の耐久性が問題になりますが、IBM FlashSystem では、エントリーモデルであっても耐久性が高いパーツを採用。「コストを抑えたモデルを選んだら、パーツの耐久性に問題があった」などのリスクがなく、どのモデルもパフォーマンスと耐久性を兼ね備えています。 IBM FlashSystem ならここまでできる! 活用シーン別にみる導入メリット では、IBM FlashSystem のメリットについて活用シーンとあわせて紹介しましょう。   高速なデータ圧縮で、データベース・テキストのデータ量を大幅削減 上記で紹介した FCM のデータ圧縮が適しているのが、データベースやテキストデータの圧縮です。特にデータベースでは、データ量を7~8割削減※という試算もあり、大きな効果を期待できます。 ハードウェアベースで処理を行うため、データ量やモジュール数が増えても性能が落ちません。 ※出典:IBM 季刊誌「ProVISION No.77」より   仮想環境・リモートデスクトップ環境で効果大!重複排除機能も搭載 データ圧縮と似た機能と思われがちな重複排除ですが、その役割は大きく異なります。 こちらは、仮想サーバーを複数台立ち上げている仮想環境や、クライアントOS を大量に利用しているリモートデスクトップ環境などで有効です。サーバーやデスクトップを複数台稼働させたとしても OS のデータはほぼ同じため、重複排除によりデータを大幅に削減できるのです。 IBM FlashSystem は、データ圧縮と重複排除の両機能を搭載していることがメリット。用途にあわせて使い分けることができます。   複数ベンダーのストレージを一元管理できる「ストレージ外部仮想化」 「既存のストレージもそのまま使い続けたい、管理負荷は最小限に抑えたい」、そんな要望に応えるのが、IBM FlashSytem の「ストレージ外部仮想化」機能です。 スイッチを介して IBM FlashSystem に接続することで、他社のストレージであっても一元管理できます。重複排除やデータ圧縮など、IBM FlashSystem ならではの機能も同様に使えるようになります。 ストレージ間のデータ移動も容易になる上、データの自動階層化機能「EasyTier」を使えば「比較的古い・低速なストレージに利用頻度の低いデータを配置する」、また「比較的新しい・高速なストレージに利用頻度の高いデータを配置する」、といったことも簡単に設定できます。   オールフラッシュストレージ選定の有力候補に 2013年にリリースされた IBM FlashSystem ですが、リリース当初の性能面を重視したラインナップから、近年は上述したデータ圧縮や重複排除、ストレージ外部仮想化などの機能を搭載し、市場のニーズに応えるラインナップへと大きく変化を遂げています。 さらに、パブリッククラウド上で展開できる「IBM Spectrum Virtualize for Public Cloud」とあわせて利用すれば、ハイブリッド・クラウド環境として一元管理することも可能です。 ストレージ最適化やクラウド連携など、エンドユーザの目線でより活用しやすいストレージへと進化する IBM FlashSystem。今後のバージョンアップにも期待できます。 オールフラッシュストレージに必要な機能が揃い、クセのない設計でパフォーマンスを活かすことができる上、チューニング次第でさらに性能を伸ばすことも可能です。幅広いラインナップで、汎用的な用途からスピードを重視する構成、複数ストレージの一元化、クラウドとの連携まで、様々なシーンに対応。 オールフラッシュストレージを選定する際は、まず IBM FlashSystem を検討してはいかがでしょうか?     参考情報 (製品情報)IBM ストレージ製品 (製品情報)IBM Spectrum Virtualize for Public Cloud (コラム)全包囲網。。。最新 IBMストレージ 概要  

2020年12月22日

IBM Power Systemsユーザーのクラウド移行ニーズに寄り添う「Cloud Power」の魅力に迫る

IBM Power Systems で基幹システムを運用する国内企業の多くは、ハードウェアの EOS やシステムを熟知した人材の退職といった課題に頭を悩ませていますが、ここ最近新たな悩みが加わっているようです。 データセンター事業者がビジネスの選択・集中を進めた結果、IBM i や AIX を扱うデータセンターが減少し、行き場を失うケースが増えているのです。 クラウドファーストが既定路線となるなか、コロナ禍も重なりオンプレミス廃止を検討する企業が増えていますが、いまさら自社内にオンプレミス構築することは考えづらい状況です。 こうした企業に向けて、末永く安心して利用し続けられる IBM i や AIX の環境をクラウド型で提供するのが、エヌアイシー・パートナーズ株式会社(以下NI+C P)の「Cloud Power」です。 以下では、IBM Power Systems をオンプレミスで利用する企業や、こうした企業を支援するパートナー企業にとってのメリット(特長)にフォーカスしつつ、具体的な導入事例についても紹介します。   事業者統合が進むなか、 データセンターサービスの選択肢が限定される傾向に ここ数年の国内 IaaS/PaaS 市場規模(事業者売上高ベース)は大幅に拡大し、2021年以降も引き続きハイペースで拡大し続けるものと予測されています。直近では、これまで取り残されていた感もあった金融業の勘定系システムや一般企業の基幹系システムについても、クラウド移行を検討するケースが。 一方、データセンター市場においては大手データセンター事業者による中小規模事業者の買収が進み、AWS・Azure・Google Cloud など主要クラウドベンダ向けのハイパースケールデータセンターの開発・運営に資本が集中投下されています。 こうしたメガトレンドのなかで IBM i や AIX のデータセンタービジネスが縮小し、国内企業に影響がおよんでいるというのが、冒頭で解説した事象の背景です。 データセンター事業者のホスティングサービスが利用できなくなることも深刻ですが、オンプレミスで IBM Power Systems の基幹システムを運用している企業にとっても、利用可能なサービスの選択肢が少なくなるという意味で影響は少なくありません。   国内企業のニーズに寄り添う人気の IaaS「Cloud Power」 今後データセンター事業者の統合やサービスの集約がさらに加速すると予測されるなか、IBM Power Systems の基幹システムを運用している国内企業が安心して利用し続けられるクラウド移行先として、「IBM Cloud」を思い浮かべる方もいるかと思います。 2019年の RedHat 買収にともない、Linux や Kubernetes などのオープンソース・テクノロジーで構築されたハイブリッド・クラウド・プラットフォームを提供する IBM Cloud では、IBM i や AIX のプライベート IaaS「IBM Power Systems Virtual Server」を2020年11月より国内で提供開始しています。 北米・ヨーロッパ・オーストラリアにリージョン展開しており、グローバルでビジネスを展開する国内のエンタープライズ企業などにとって有力な選択肢となるでしょう。 そんな中、情報システム部門のリソースが限定されていて導入(環境構築)から運用に至るまできめ細かなサポートを期待する企業には、IBM製品の国内ディストリビューターとして製品に関する豊富なノウハウを有する NI+C P の「Cloud Power」をお勧めします。 同サービスは、グループ親会社である NI+C のデータセンターにて IBM Power Systems を基盤に、IBM i および AIX環境を提供するクラウドサービス(IaaS)で、2009年にサービスを開始。2020年6月現在、75社200区画にてサービス提供しており、ここ1年で70区画が新規導入されています。 クラウドサービスとして、ハードウェアの保守切れなどを気にすることなく常に最新のハードウェア環境を利用できるほか、以下のようなメリットを導入企業に提供します。   OSアップデートなど、システム基盤の維持・運用はおまかせ オンプレミスで IBM Power Systems を運用する企業にとって、セキュリティ対策や OS/ファームウェアのアップデートなど定期的なメンテナンスは重荷ですが、Cloud Power では Q&A 対応サービスを含め豊富な運用サービスのオプションメニューを用意。 リソースを投入し時間をかけて社内でスキルを習得することなく、OS のバージョンアップ、リソース監視、ライセンス管理など、ほとんどの作業をアウトソースでき、業務の自動化や効率化など戦略的な取り組みに注力できるようになります。 なお、メンテナンスは LPM※を利用することで OS を停止させることなく行われ、業務への影響を心配しなくて済みます。 ※Live Partition Mobility:稼働中の LPAR を別の筐体に移動する機能   ネットワークもワンストップ提供。設定や保守もおまかせ IaaS 利用では、クラウド環境に接続するネットワーク回線をどうするか?も問題となります。 特に、機密情報や個人情報などを扱うケースでは盗聴などのリスクを排除するため、専用線や閉域網などセキュアなネットワーク回線が必須となりますが、Cloud Power では「NMS Plus セキュアドネット」という独自の回線を提供。ワンストップで導入することが可能です。 ブロードバンド接続のベストエフォート型は5.5万円で、そのほか、リーズナブルなインターネットVPN型や、速度保証のある専用線型も用意され、ニーズや用途にあわせて選べます。   東西に堅牢なデータセンターを保有。DR/BCP 対策も可能 Cloud Power のデータセンターは関東と関西の2か所にあり、ミッションクリティカルなシステムを両データセンター間でレプリケーションすることで、万が一の際にもビジネス継続性を確保できます。 なお、Cloud Power は24時間365日体制の保守・運用により、被災以外の障害発生にも迅速対応が可能です。   実際の導入事例に見る「Cloud Power」活用シナリオ 以下、実際に Cloud Power を導入した3社の事例でその活用メリットを紹介します。   【事例 1】 Oracle SE2ライセンスの流用をハイブリッドクラウドで実現 アプリの検証環境を自社ビル内で運用する大手 SIer A社は、毎年の法定点検にともなう停電でシステム停止を余儀なくされ、そのたびに調整や事後の対応に追われていました。 こうした事態から脱却しより柔軟なリソース増減を実現するため、クラウドへの移行を検討するも、Oracle SE2 はソケット数制限で利用できず、Oracle EE はコストが過大になることが判明。 そこで、NI+C のデータセンター内に Oracle SE2 のサーバーをコロケーション設置。併せて Oracle SE2 以外のシステム(AIX)を Cloud Power に移行するハイブリッドクラウド構成により、既存の Oracle SE2 ライセンスを活かして、オンプレミス環境と同等のコストでクラウド移行すると同時に運用管理の工数削減を実現しました。   【事例 2】 新旧災対環境間の切り替えにより、システム停止を最小化してクラウド移行 利用していたデータセンター閉鎖が決まり、基幹システム(IBM i)の移行先を探すことになった大手運送業B社。 同社のビジネスを支えるクリティカルなシステムのため、いかにビジネスへの影響を最小化して移行できるかが重要なポイントに。 既存の DR環境を維持しつつ、Cloud Power を導入し東西データセンターの HA構成を採用することで、システム停止を最小限にとどめて切り替えを実施。本来数日を見越していたシステム停止が約1日で済み、データ移行についても、HAソフトウェアを採用することで物理テープを利用した場合の半分以下の期間で完了しました。 また、既存データセンターに設置していた多数の NW機器においてもホスティングサービスを新たに契約し、NI+C のデータセンターに収容することで、基幹システム以外についてもクラウド移行を果たしました。   【事例 3】 IAサーバーや EDI通信を含むネットワーク基盤の移行も、ワンストップ化 ハードウェアの老朽化などを理由に利用していたデータセンターを退去することになった商社C社。 IBM i のほか、AIXサーバーや IAサーバー、サービス終了が迫るベーシック手順の通信を利用する EDI やネットワーク基盤などを、必要に応じアップデートしつつ、移行するための工数が大きな負担に。 Cloud Power のオプションメニューや構築支援サービスを利用することで、自社の工数負担を最小化して、ネットワークを含むすべてのシステム基盤の移行をスムーズに進行中です。   再販パートナーと一体になって充実サポートを提供 Cloud Power は、再販パートナーを通じてエンドユーザーに提供されます。 長年にわたり顧客企業と良好な関係を築いてきた SIer などにとっては、お客様の IBM Power Systems 環境の構築・運用で蓄積したノウハウを最大限活かすことができます。 これまでオンプレミス中心で、クラウドならではの扱いに少し不安を感じるというケースでは、NI+C P が一体となり課題に対して1つひとつ対応するので安心して導入いただけます。 Cloud Power の導入検討についてはもちろん、IBM Power Systems基盤をご利用のお客様は、ぜひ、NI+C P にご相談ください。     ◆この記事に関するお問合せ◆ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは、「こちら」からお願いします。   参考情報 (製品情報)Cloud Power (ソリューション)Withコロナ時代の NI+C P お勧めソリューション (コラム)コロナ禍で基幹システムでもクラウド移行が急拡大!の背景を探る

2020年12月03日

「2025年の崖」を克服するアプリケーション・モダナイゼーションとは 〜「IBM Cloud Pak for Applications 」の2つの優位点と3つの価値〜

IBM Cloud Pak for Applicationsの新規販売は終了いたしました。 今後のアプリケーションランタイムソリューションは、2021年1月15日に発表されたWebSphere Hybrid Editionとなります。 現在、日本の多くの企業にとって「2025年の崖」をいかに克服するかが大きな課題となっている中で、レガシーシステムの抱える数々の問題が足かせになっています。 本コラムでは、"企業が抱えるレガシーシステム特有の課題を解決してデジタルトランスフォーメーション(以下:DX)を実現するためには、なぜ新しいアプリケーション開発や既存アプリケーションのモダナイゼーションが必要なのか?" について考察します。   DX実現にアプリケーションのモダナイゼーションが必要な理由 レガシーシステムが抱える問題 2000年代に構築した基幹システムを現在に至るまで改修を繰り返しながら利用しているケースは珍しくありません。これらのシステムは今や15年〜20年が経過しており、レガシーシステムと呼ばれています。 既存のレガシーシステムは属人性が高く、さらに、レガシーシステムを運用・保守できるスキルを持った人員は不足しているので、それにともなう運用・保守コストの増大は大きな課題です。また、アプリケーションの改修に数ヵ月単位の工数がかかってしまうため、柔軟性や迅速性の低下も課題となっています。 レガシーシステムを抱える企業の問題 システム開発・管理の「属人化」による、弊害 運用・保守のコスト増大による、新規開発への投資不足 スキル要員の不足による、新規案件への対応の遅れ 「外部連携ができない」システムによる、デジタル・ビジネス創出の損失 アプリケーション構造による、業務の拡大や変化に対する制約 データへのアクセスの難しさによる、データ資産の利活用不足 ビジネススピードを左右する、「アプリケーションの開発サイクル」の遅れ 迅速性・柔軟性の低下による、新業務・新商品の投入の遅れ 複雑化した構造による、開発・保守の生産性・品質の低下 これらレガシーシステムを抱える企業の問題は、DX がめざすビジネス変革に対する制約となっており、差し迫った足元の課題としてこれを解決することが必要不可欠です。   「マイグレーション」と「モダナイゼーション」の違い レガシーシステム特有の課題を解決し DX を実現するために不可欠な手法として、「モダナイゼーション」があります。 モダナイゼーションを検討するにあたっては、まず「マイグレーション」と「モダナイゼーション」の違いを知っておくことが大切です。   マイグレーションとは、「TCO削減」を目的としたクラウド環境への移行 マイグレーションは、TCO(総所有コスト)の削減を主要な目的としたクラウド化のことをいいます。具体的には、既存のアプリケーションの構造を変えることなくクラウド環境に移行することです。 マイグレーションによる成果としては主に以下が挙げられます。 迅速にアプリケーションのクラウド化が可能 クラウド化による IT資源の効率的利用 運用効率化・自動化を取り入れた設計指向   モダナイゼーションとは、「ビジネス拡大」を目指すクラウド・ネイティブ化 モダナイゼーションは、マイグレーションによりコスト削減を狙う領域を見定めつつ、戦略領域についてはモダナイゼーションによりビジネス拡大を目指すクラウド・ネイティブ化のことをいいます。具体的には、クラウド・ネイティブ化することで既存アプリケーションのアプリケーション構造を変革し、最新技術を取り入れ最適化することです。 モダナイゼーションによる成果としては主に以下が挙げられます。 将来にわたってアプリケーションの保守・管理が継続できる環境を整備 API化によるビジネス機会の拡大 Agile/DevOps (アジャイル/デプオプス) によるビジネス要求への迅速な対応   クラウド・ネイティブ化のメリット このように、アプリケーション・モダナイゼーションは現行のアプリケーションを最新技術で更改し、「ビジネスの成長と拡大」を目的として「クラウド・ネイティブ化」することで新たな価値を生み出すよう変革することを意味します。 クラウド・ネイティブとは「クラウドの利点を徹底的に活用するシステム」を意味しており、様々なクラウドサービスを利用して開発・構築された、クラウドでの運用を前提としたシステムやサービスです。 そのメリットは、既に提供されているサービスを使うことによる開発期間の短縮や、アプリケーションを細分化することにより改修時の影響範囲が小さくなることによって修正期間・工数の削減ができる、などが挙げられます。昨今では、IaaS を用いて既存のシステムを最小限の改修でクラウドに移行し、その上で、PaaS や SaaS を活用してクラウド・ネイティブに作り替える「リフト&シフト」と呼ばれる手法も広まっています。 つまり、アプリケーション・モダナイゼーションによってレガシーシステムを「クラウド・ネイティブ化(Shift)」することでアプリケーション開発および管理の場を最適化し、レガシーシステムの課題であった「可用性」「スケーラビリティ」「リリースまでの期間短縮」などの問題を解決することができるのです。 参考)「CNCF Cloud Native Definition v1.0」   モダナイゼーションの事例 2018年に経済産業省の DXレポートが公開されて以降、多くの企業がブラックボックス化したレガシーシステムを様々なレベルで刷新し、「2025年の崖」を克服するべく DX 実現のための IT基盤整備に取り組んでいます。 ここで、モダナイゼーションの事例を幾つか紹介しましょう。   サイロ化されたインターネットサービスを改善 この企業では、部分最適によってサイロ化され、利便性が低くなったインターネットサービスを改善する必要に迫られていました。 アプリケーションフレームワークに Struts* を採用していたためにセキュリティ上の問題も抱えており、そのほかにも、各種キャッシュレス決済の技術を採用することや、ソーシャルメディア連携を強化して新しいビジネス領域を開拓する必要もありました。 これに対して同社は、ToBe アーキテクチャとして、フレームワーク更改や PaaS化、コンテナ化/マイクロサービス化、DevOps 適用を採用。 最新のアプリケーションフレームワークを導入し、コンテナ化による保守性と拡張性の高いアプリケーション構造を実現しました。さらに、DevOps によって新しいサービスをタイムリーに実装・展開できるようになりました。 *Struts : Java Servlet API を拡張してMVC (Model, View, Controller) アーキテクチャを採用した、オープンソースのフレームワーク   レガシーシステムに散在していた顧客データを収集・集約 またある企業では、顧客データが事業ごとに散在して再利用が困難になっており、ガバナンスにも課題がありました。また、システム構造がサイロ化していたため、アプリケーションのリリースサイクルが長期化していることも問題となっていました。 これに対して同社は、ToBe アーキテクチャとして UXモダナイゼーション、SoE/SoR分離、コンテナ化/マイクロサービス化、DevOps 適用を採用。 レガシーシステムに散在していた顧客データを収集し、IBM が提唱する、次世代アーキテクチャに従った変化に強いデジタルサービス層に集約しました。さらに、マイクロサービスのアプリケーションをコンテナで実装することで柔軟性の高いシステム構造を実現しています。   レガシーシステムのデータはそのままに、メインフレーム資産を API連携 メインフレームを利用していたある企業は、レガシーシステムのデータはそのままに、フロント側の各チャネルにデータを提供したいと考えていました。 これに対して同社は、ToBeアーキテクチャとして API化、SoE/SoR分離、コンテナ化/マイクロサービス化を採用。次世代アーキテクチャのデジタルサービス層にアプリケーション基盤、API管理基盤を設けることで、メインフレーム資産をシンプルに API連携させています。   アプリケーションのモダナイゼーションを推進する 「IBM Cloud Pak for Applications 」 モダナイゼーションとクラウド・ネイティブ・アプリケーション開発・実行を サポートする「IBM Cloud Pak for Applications 」 レガシーシステムの問題点を解決し、オープンなコンテナ技術によるアプリの可搬性向上と、オープンなオーケストレーションによる管理・運用の効率化を実現するのが IBM Cloud Paks シリーズです。 IBM Cloud Paks とは、Red Hat OpenShift 上で稼働するミドルソフトウェア群で、オープンなコンテナ技術によるアプリの可搬性向上と、オープンなオーケストレーションによる管理・運用の効率化を実現します。 Red Hat OpenShift とコンテナ化された IBMソフトウェアを含み、オンプレミス、プライベートクラウド、パブリッククラウド、エッジ・コンピューティングを同じアーキテクチャで提供します。エンタープライズでは、オープンソースそのものだけでは難しく、運用の負荷も増大します。 IBM Cloud Paks は、他社の Kubernetesサービスと比べて、運用サービスがエンタープライズ用に共通化されており、ソフトウェアが最適化された形で提供されます。ユースケース別に6製品があり、そのなかで、アプリケーションのビルド、拡張、デプロイ・実行を支援する製品が、「IBM Cloud Pak for Applications」です。   IBM Cloud Pak for Applications の2つの優位性 IBM Cloud Pak for Applications は、既存のアプリケーションを最新化し、Red Hat OpenShift で実行するクラウド・ネイティブのアプリケーションを新規開発するための、エンタープライズ対応のコンテナ化されたソフトウェア・ソリューションとして提供されています。 CI/CD開発・実行環境である「Accelerators for Teams」とコードのモダナイゼーションをアドバイスする「Transformation Advisor」の2つの優位点があり、開発者、IT運⽤者、LOB (Line of Business) それぞれに、大きなメリットを与えます。 「IBM Accelerators for Teams 」は、従来型のアプリケーションのハイブリッドクラウド/マルチクラウドへの移行を支援するとともに、必要なツールとランタイムを使用して革新的なクラウド・ネイティブ・アプリケーションを開発できる基盤を提供します。 また「Transformation Advisor」は、既存のレガシーシステムのアプリケーションをコンテナ上で実行できるかを分析し、必要な手順を教示することでコンテナ環境への移行をサポートします。   IBM Cloud Pak for Applications の3つの価値 先程ご説明した2つの優位点は、いま必要なものから将来必要となるものまで、お客様にとって3つの価値を提供します。   既存アプリの実行 : 現在の環境で、従来どおりアプリケーションを実行 - パブリッククラウド、オンプレミス、プライベートクラウドのどこでもアプリケーションが 実行可能 - IBM Cloud Pak for Applications は、既存のアプリケーションが存在する場所で実行し、最新化されたアプリケーションと新しいクラウド・ネイティブのアプリケーションをコンテナ内のクラウドにデプロイします。そのため、パブリッククラウド、オンプレミス、プライベートクラウドのどこでも、ビジネスに最適な場所と方法でアプリケーションを実行できます。 また、既存のアプリケーションに対して、オープンソース標準に基づいて構築された統合 Kubernetesプラットフォームである Red Hat OpenShift に合わせたツールを提供するとともに、アプリケーションの実行場所にかかわらずそれらをサポートします。   既存アプリのモダナイズ : コンテナ環境へ移行が必要となったときに、それをサポートする ツール・知見を提供 - 既存システムのリフト&シフトを支援ツール「Transformation Advisor」を活用可能 - IBM Cloud Pak for Applications には、既存アプリケーションのモダナイゼーションを支援するツールとして、「Transformation Advisor」が用意されています。これは、オンプレミス環境で実行されていた Java EE のアプリケーションをコンテナ上で実行できるかを分析し、どういう手順が必要かをレポートするなど、既存システムのリフト & シフトを支援します。 また、「WebSphere Migration Toolkit」やローカル開発と連携する IDE 拡張機能などにより、コンテナ環境への移行をサポートします。   新規アプリの開発 : 新規アプリケーションをクラウド・ネイティブで作成するための 開発ツールや環境、各種オープンソースを統合して提供 -「Accelerators for Teams」フレームワークに含まれている各種オープンソースを サポート付きで開発可能 - IBM Cloud Pak for Applications には、複数のオープンソースを組み合わせてコンテナ上のアプリケーションを開発・テスト・管理できるようにした「Accelerators for Teams (旧 Kabanero) 」が含まれます。 ツールをひとつひとつ組み合わせて開発環境を構築するのは容易ではありませんが、「Accelerators for Teams」は開発者がすぐに使えるかたちで提供されており、しかも IBM のサポートが付いているので安心して利用することができます。 また、テンプレートや管理のためのアーキテクト・ツール、開発者向けツールなども充実。Accelerators for Teams で作成したアプリケーションをテスト・本番で実行するランタイムも各種用意されており、なかでも「Libertyランタイム」はスピーディーな開発に対応する軽量の次世代ランタイムです。これにより、自動化された環境で最小人数のエンジニアでの開発が可能となります。   このように、OpenShift ベースの基盤でコンテナ化することでハイブリッド・クラウド/マルチ・クラウド双方に対応し DX を加速させる IBM Cloud Pak for Applications は、これを利用することで既存アプリケーションの利用、モダナイゼーション、新たなネイティブ・アプリケーションの開発がスムーズに行えるようになります。 アプリケーション・モダナイゼーションを検討する上で、IBM Cloud Pak for Applications はエヌアイシー・パートナーズが自信をもってお勧めするソリューションです。     この記事に関するお問合せ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは、「こちら」からお願いします。   参考情報 (製品情報) IBM Cloud Pak for Applications (コラム) 今、デジタルサービスに求められる必須要件とは!?アプリケーションのコンテナ化で得られる5つのメリット (ブログ)【やってみた】Cloud Pak for Applications 導入してみた:Cloud Pak for Applications 導入編 (資料) IBM Cloud Paks シリーズ ご紹介資料 (IBM サイト) IBMデモ Cloud Pak for Applications  

2020年11月30日

10GbpsEtherは何を選べばよいの?

こんにちは。てくさぽBLOG新メンバーの佐藤です。 最近でも、10GbpsEtherを含めたサーバの構成依頼を多くいただきます。 種類がいくつかありますので、どの10GEtherにしましょうか?と確認すると 種類が多すぎてどれにしていいかわからない、どうお客様にヒヤリングしていいかわからない といったお困りの声が多いため 今回は、何を選定していいか迷ってしまいがちな「10GbpsEther」について改めて解説いたします。 10GbpsEtherとは? 読んで字の通りですが従来のGbitEtherの後継で10倍の転送速度を持つEtherとなります。 10GbpsEtherの難点は複数の種類があるところです。 代表的なものを以下にあげます。 なお、これ以外にもありますが現在あまり販売していないもの、WAN回線用の長距離通信の規格については除いています。 ・10GBASE-T ・10GBASE-SR ・10GBASE-LR ・10GBASE-SFP+ それぞれについての技術的な解説等は多数のサイトにお任せするとして 本ブログでは、 何を選択すればいいか?に焦点を絞って解説致します。 10GbpsEtherを選定する際は基本的には以下の2つの要素から決めます。 1.汎用性 2.配線距離 1.汎用性 2016年8月現在、サーバに搭載する10GbpsEther汎用性ランキング*は以下の通りです。  *個人的な感覚を含みます。 ランキング 名称 成長率 1位 10GBASE-SFP+ → 2位 10GBASE-T ↑ 3位 10GBASE-SR → 4位 10GBASE-LR → 1位は10GBASE-SFP+としています。 今買うのであればもっとも普及しており、汎用性が高い規格となります。 スイッチの種類も豊富です。 ただし、今後は10GBASE-Tの動向次第といったところです。 2位の10GBASE-Tは、期待を背負って最後に登場した規格となりますが 様々な理由から穏やかに成長しており、価格的にも今のところは10GBASE-SFP+と同じくらいです。 しかしながら、RJ-45コネクタおよびメタルケーブル接続という潜在的なコストメリットは最も高いため、今後普及がさらに進めば価格が下がることが期待されます。 3位以下は次にあげる配線長の理由が無い限り特に大きなメリットが感じられません。 2.配線距離 各規格の最大配線長は以下の通りです。 配線長 名称 種類 ~10m 10GBASE-SFP+(Cu Twinnax) メタル ~100m 10GBASE-T メタル ~300m 10GBASE-SR 光(MMF) ~10km 10GBASE-LR 光(SMF) SFP+(Cu Twinnax)はダイレクトアタッチケーブルと呼ばれるものです。 最大10m以下となりますので、実質ラック内配線専用となります。 10GBASE-Tの最大長は最も高品質なCat6a/Cat7ケーブルを使った場合で100mまで、Cat6/Cat6eですと55mまでとなります。 そのため、データセンターなどの広いフロア内の配線や、上下階配線ではやや物足りない長さとなります。 10GBASE-SRはOM3という高品質光ケーブルを使用すると300mまで伸ばすことができます。 300mあれば、フロア内配線で困る事は無いでしょう。 10GBASE-LRは最大長10kmと敷地内の棟をまたぐような特別長い配線をする場合に必要になります。 基本的にスイッチ間接続が主用途となります。   10GBASE-SFP+ ここで、SPF+について補足します。 上記の通り、10mまでしか配線出来ないのであればSPF+は汎用性高くないではないか? と疑問に思われる事でしょう。 しかし、SFP+は、モジュールを選択することによって10GBASE-SFP+(Cu Twinnax)と10GBASE-SR両方に対応可能です。 たとえば、ラック内配線では10GBASE-SFP+(Cu Twinnax)で安価に、ラック外との接続はSRトランシーバーを使用し光ファイバで接続といった具合に、メタルケーブルの経済性と光ケーブルの長距離、高品質を両立させることができます。 設置環境の情報が不明なケースが多いため、私はもっとも汎用性が高いSFP+を選択することが多いです。 10GBASE-SFP+(Cu Twinnax)_ダイレクトアタッチケーブルの例 10GBASE-SFP+ SRトランシーバモジュールの例 まとめ さまざまな規格が存在する10GbpsEtherの世界ですが、今から購入するのであれば10GBASE-SFP+か10GBASE-Tのどちらかとなります。 今のところ迷ったり、指定がない場合、汎用性と配線距離を踏まえてSFP+を選択します。 10GBASE-Tについては、現状ではSFP+と比較して ・RJ-45ではあるが、ケーブルを引き直す必要が有り、配線を流用できない ・最大ケーブル長がSFP+と比較して短い ・消費電力が高め(改善されつつある) ・高レイテンシ となり、積極的に選ぶか?といわれると意見の分かれるところになります。 敷設のしやすさ、ケーブルの取り回しのしやすさ1GbpsEtherとの接続性といった点を 評価するのであれば 10GBASE-Tとなります。 普及が進み、スイッチ含め、価格がもう一段下がれば基本は10GBASE-Tで構成となるかと思います。 ※SFP+ダイレクトアタッチケーブルを使用する場合の注意点(2018/11/2追記)※ SFP+のダイレクトアタッチケーブルですが、ネットワークスイッチ側で制限がかけられているケースがあるようです。 具体例ですとCISCOのCatalystシリーズと接続する場合はCISCO以外のメーカーのケーブルを接続するとリンクアップしないようです。 Catalystの場合、回避策がありますので知りたい方は”#no errdisable detect cause gbic-invalid”や”#service unsupported-transceiver”で検索ください。 ダイレクトアタッチケーブルの場合、サーバーとネットワークスイッチのメーカーが違う場合は相互にサポートするケーブルはありませんのでサポートを気にされる場合は、SRトランシーバーでの接続をお勧めいたします。 以下は、ダイレクトアタッチケーブルの適合性についての資料となりますがこちらのリンク先の資料については、各メーカーのサポート状況をまとめたものではなく、あくまで互換SFP+モジュールを販売しているPanduit社の調査結果に基づくデータとなります。 こちらの情報で使用可能となっていても、メーカーのサポートは受けられない、もしくは動かないケースもあり得ます。 あくまで自己責任の範囲でご参照ください。 http://www.panduit.com/heiler/TechnicalReferences/D-COTR104--WW-JPN-Rev2-SFPCprCblAsmbl.pdf http://www.panduit.com/heiler/TechnicalReferences/D-COTR104--WW-ENG-Rev5-SFPCprCblAsmbl.pdf 25GbpsEtehrの記事も追加しております。 ↓↓↓↓↓↓↓↓↓↓↓↓↓↓ いまさら聞けない25GbpsEther この記事に関する、ご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail:nicp_support@NIandC.co.jp

2020年11月13日

【やってみた】IBM Cloud Pak for Applications 導入してみた:Cloud Pak for Applications 導入編

IBM Cloud Pak for Applicationsの新規販売は終了いたしました。 今後のアプリケーションランタイムソリューションは、2021年1月15日に発表されたWebSphere Hybrid Editionとなります。 こんにちは。 てくさぽ BLOG メンバーの岡田です。 第1回、第2回に続いて、今回は AWS 上に構築した Openshift 環境に Cloud Pak for Applications(以下、CP4A)をインストールします。 手順は Knowledge Center 内「Installing」の内容に基づいていますのでこちらもご参照ください。 【環境】 Openshift 4.3.22 (AWS 上に CloudFormation を用いて構築) CP4A 4.0.1   目次 事前準備 インストール実行 2-1.Entitlement Key の入手 2-2.インストール構成ファイルをインストーライメージから取り出す 2-3.インストーラの実行 2-4.インストール後の確認 つまづいたポイント 最後に     1.事前準備 IBM id を用意します。 Docker コマンド 17.05 以上の実行環境を用意します。 構築した Openshift 環境に ocコマンドでログインできることを確認します。   2.インストール実行 2-1.Entitlement Key の入手 < "MyIBM Container Software Library" にアクセスし Entitlement Key をコピー> ※アクセスすると IBM id でのログインが求められるので ID・パスワードを入力してログインし、以下の画面に遷移したら「キーのコピー」をクリックします。   2-2.インストール構成ファイルをインストーライメージから取り出す <以下のコマンドを、docker をインストールした端末から実行> # export ENTITLED_REGISTRY=cp.icr.io # export ENTITLED_REGISTRY_USER=cp # export ENTITLED_REGISTRY_KEY=<apikey> ※apikeyは2-1.でコピーしたライセンス・キーです。 <entitled registry にログイン> # docker login "$ENTITLED_REGISTRY" -u "$ENTITLED_REGISTRY_USER" -p "$ENTITLED_REGISTRY_KEY" WARNING! Using --password via the CLI is insecure. Use --password-stdin. WARNING! Your password will be stored unencrypted in /root/.docker/config.json. Configure a credential helper to remove this warning. See https://docs.docker.com/engine/reference/commandline/login/#credentials-store Login Succeeded <dataディレクトリを作成し、そこに configurationファイルを展開> # mkdir data # docker run -v $PWD/data:/data:z -u 0 -e LICENSE=accept "$ENTIITLED_REGISTRY/cp/icpa/icpa-installer:4.0.1" cp -r "data/*" /data Unable to find image 'cp.icr.io/cp/icpa/icpa-installer:4.0.1' locally 4.0.1: Pulling from cp/icpa/icpa-installer 964d57e311cc: Pulling fs layer 6d1814359c74: Pulling fs layer 77181019ed4d: Pulling fs layer 60aa381192cc: Pulling fs layer (途中省略) 2.602kB/2.602kB7d09be603f64: Extracting 2.602kB/2.602kB7d09be603f64: Pull complete df8e82fdbe08: Extracting 32.77kB/925.6kBdf8e82fdbe08: Extracting 925.6kB/925.6kBdf8e82fdbe08: Pull complete b0cda391a0db: Extracting 32.77kB/973kBb0cda391a0db: Extracting 973kB/973kBb0cda391a0db: Extracting 973kB/973kBb0cda391a0db: Pull complete Digest: sha256:a1c6c478dfb4d2039df385f8a75ecf3e6d358e35f8d662afc506b6bbc5d308af Status: Downloaded newer image for cp.icr.io/cp/icpa/icpa-installer:4.0.1 # <dataディレクトリに4つの yamlファイルが作成されたことを確認> ※config.yaml, kabanero.yaml, servicemesh.yaml, transadv.yaml が作成されます。 # ls -la data 合計 20 drwxr-xr-x. 2 root root 91 4月 21 10:44 . dr-xr-xr-x. 21 root root 4096 4月 21 10:40 .. -rw-r--r--. 1 root root 704 4月 21 10:44 config.yaml -rw-r--r--. 1 root root 539 4月 21 10:44 kabanero.yaml -rw-r--r--. 1 root root 1299 4月 21 10:44 servicemesh.yaml -rw-r--r--. 1 root root 3792 4月 21 10:44 transadv.yaml   2-3.インストーラの実行 <Openshift 環境へログイン> # oc login https://api.nicptestcluster.example.com:66443 -u kubeadmin -p 〈kubeadminのパスワード〉 Login successful. You have access to 51 projects, the list has been suppressed. You can list all projects with 'oc projects' Using project "default". <チェックコマンドの実行> ※最後に "Check successful" と表示されることを確認します。 # docker run -v ~/.kube:/root/.kube:z -u 0 -t -v $PWD/data:/installer/data:z -e LICENSE=accept -e ENTITLED_REGISTRY -e ENTITLED_REGISTRY_USER -e ENTITLED_REGISTRY_KEY "$ENTITLED_REGISTRY/cp/icpa/icpa-installer:4.0.1" check Starting Check ***************************************************************** Login To Cluster... ok stdout: Using environment variables to log-in to cluster. Login successful. You have access to 57 projects, the list has been suppressed. You can list all projects with 'oc projects' Using project "openshift-marketplace". Get Cluster Server Address... ok (途中省略) Check Existing OpenShift Serverless Subscription... skipped Check Existing OpenShift Pipelines Subscription... skipped Check Existing Appsody Subscription... skipped Check successful *************************************************************** <インストールの実行> ※チェックコマンドで問題がなければ実行します。チェックコマンドとは最後のパラメータが "check" か "install" かの違いです。 最後に "Installation complete" と表示されることを確認します。 # docker run -v ~/.kube:/root/.kube:z -u 0 -t -v $PWD/data:/installer/data:z -e LICENSE=accept -e ENTITLED_REGISTRY -e ENTITLED_REGISTRY_USER -e ENTITLED_REGISTRY_KEY "$ENTITLED_REGISTRY/cp/icpa/icpa-installer:4.0.1" install Starting Install *************************************************************** Login To Cluster... ok stdout: Using environment variables to log-in to cluster. Login successful. You have access to 57 projects, the list has been suppressed. You can list all projects with 'oc projects' Using project "openshift-marketplace". Get Cluster Server Address... ok (途中省略) Mark Installation Complete... done Install successful ************************************************************* Installation complete. Please see https://ibm-cp-applications.apps.nicptestcluster.example.com to get started and learn more about IBM Cloud Pak for Applications. The Tekton Dashboard is available at: https://tekton-dashboard-tekton-pipelines.apps.nicptestcluster.example.com. The IBM Transformation Advisor UI is available at: https://ta-apps.apps.nicptestcluster.example.com. The IBM Application Navigator UI is available at: https://kappnav-ui-service-kappnav.apps.nicptestcluster.example.com.   2-4.インストール後の確認 <インストール画面に表示された Cloud Pak Console の URL にアクセス> https://ibm-cp-applications.apps.nicptestcluster.example.com/ ※Cloud Pak Console には OpenShift Webコンソールからもアクセスできます。 画面右上の四角形のアイコンをクリックすると "Cloud Pak for Applications - Cloud Pak Console" が確認できます。 以上で CP4A のインストールは完了です!   3.つまづいたポイント インストールがエラーで完了しない 作業当初は、以下のシステム要件ページに記載の "Cloud Pak for Applications 4.0.1 only runs on x86 Intel on Red Hat OpenShift Container Platform (OCP) versions 4.3 and 4.2. " より OpenShift4.2.23 上にてインストールを開始しました。 https://www.ibm.com/support/knowledgecenter/en/SSCSJL_4.0.x/install-prerequisites.html 上記 <チェックコマンドの実行> までは正常に完了しましたが、次の <インストールの実行> でエラーとなりました。 # docker run -v ~/.kube:/root/.kube:z -u 0 -t -v $PWD/data:/installer/data:z -e LICENSE=accept -e ENTITLED_REGISTRY -e ENTITLED_REGISTRY_USER -e ENTITLED_REGISTRY_KEY "$ENTITLED_REGISTRY/cp/icpa/icpa-installer:4.0.1" check Starting Check ***************************************************************** Login To Cluster... ok (途中省略) Retrying... (39 of 41) Retrying... (40 of 41) failed msg: non-zero return code stdout: The kappnav-ui pods are not created. Check logs for details. Install failed ***************************************************************** このログをみる限り、kappnav-uiポッドが立ち上がってこない状況で止まっていますので、続いて、pod のログを確認しました。 # oc describe kappnav.kappnav.io/instance -n kappnav Name: instance Namespace: kappnav Labels: <none> Annotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"kappnav.io/v1alpha1","kind":"KAppNav","metadata":{"annotations":{},"name":"instance","namespace":"kappnav"},"spec":{"appNav... API Version: kappnav.io/v1alpha1 Kind: KAppNav (途中省略) Status: Conditions: Last Transition Time: 2020-05-12T07:50:44Z Status: True Type: Initialized Last Transition Time: 2020-05-12T07:50:48Z Message: failed to install release: chart requires kubeVersion: >=1.11.0 which is incompatible with Kubernetes v1.14.6-152-g117ba1f Reason: InstallError Status: True Type: ReleaseFailed Events: <none> # 続いて Openshiftクラスターの Kubernetesバージョンを確認します。"v1.14.6+8fc50dea9" でした。 # oc get nodes NAME STATUS ROLES AGE VERSION ip-10-0-48-228.ap-northeast-1.compute.internal Ready worker 51d v1.14.6+8fc50dea9 ip-10-0-49-10.ap-northeast-1.compute.internal Ready worker 51d v1.14.6+8fc50dea9 ip-10-0-50-165.ap-northeast-1.compute.internal Ready master 52d v1.14.6+8fc50dea9 ip-10-0-58-201.ap-northeast-1.compute.internal Ready master 52d v1.14.6+8fc50dea9 ip-10-0-59-142.ap-northeast-1.compute.internal Ready master 52d v1.14.6+8fc50dea9 その後、いろいろと調査をしたのですが原因が特定できなかったため、4.0.1 がサポートしている Openshift の最新バージョン 4.3.22 にアップデートをして再度 CP4A のインストールを実施したところ、無事完了しました。 4.3.22 にバージョンアップ後の oc get nodes 結果です。4.2.23 のときについていた "+xxx" という文字列は無くなり "v1.16.2" となっています。 $ oc get node NAME STATUS ROLES AGE VERSION ip-10-0-48-228.ap-northeast-1.compute.internal Ready worker 213d v1.16.2 ip-10-0-49-10.ap-northeast-1.compute.internal Ready worker 213d v1.16.2 ip-10-0-50-165.ap-northeast-1.compute.internal Ready master 213d v1.16.2 ip-10-0-58-201.ap-northeast-1.compute.internal Ready master 213d v1.16.2 ip-10-0-59-142.ap-northeast-1.compute.internal Ready master 213d v1.16.2 原因を特定できなかったのは残念でしたが、つまづいたら一旦環境を最新にしてエラーが再現するかを確認する、という問題解決の基本を改めて実感しました。   最後に いかがでしたでしょうか。 一部の dockerコマンドが長くて難しく感じましたが、手順そのものは前回ブログでの Openshift 構築と比べると工程数は非常に少ないので、それほど CP4A のインストールは難しくないと、実際に検証してみて感じました。 皆様の CP4A 構築にこの記事が参考になれば幸いです。     この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail:nicp_support@NIandC.co.jp

2020年11月09日

最新のデータライフサイクル管理とは?(後編)

IBM の岡田です。 「最新のデータライフサイクル管理とは?(前編)」では "データの価値" や "IBM Spectrum Scale" についてのお話をしました。 後編は "IBM Cloud Object Storage" とは何か、といったことから、続きのお話をしていきましょう。   IBM Cloud Object Storageとは 先にデータの価値の話をしました。今度は昨今のデータの在り方のお話から入ります。 ここ10年ほどの間に、データの中心はトランザクション系の構造化データからビデオコンテンツや写真や IoT のセンサーデータなどの非構造化データにシフトしています。 近年その伸びも2年ごとに90%レベルの伸びを示しており、現在世の中のデータはすでに数十ゼタバイト程とも言われています。 つまり、これからのストレージはその容量の拡大についていく必要があり、そのような大容量下でデータ保全していかなければならないということです。 このような膨大な非構造化データの保管に向いているのが、オブジェクトストレージと言われるものです。(ブロック・ファイル・オブジェクトの違いはGoogle検索してみると色々解説がありますので、そちらをご参照ください) オブジェクトストレージには以下の特徴があります。 階層を持たない API による I/O 複数ノードによる分散保管 IBM Cloud Object Storage(以降 ICOS と呼ぶ)はこの複数ノードによる分散保管を地域レベルまで広げ、複数サイトでデータを持ち合う(ただしミラーではない)ことで地域災害などサイトレベルでのダウンにも対応できる保全性を実現します。 これにはイレージャーコーディングという RAID とは別のデータ保全の仕組みが使われてます。 RAID の問題点は、扱う容量が大きくなればなるほど障害後の再構成の時間がかかるようになるということ。この再構成時に新たな障害が発生するとデータロストに繋がります。 ICOS で使われる Information Dispersal Algorithm(以降 IDA と呼ぶ)というイレージャーコーディングをベースにした技術は、複数ディスク、複数ノードの障害を許容する、さらに言えば、ハードウェアは壊れることが当然、という思想の元に出てきたデータ保全方法のため、ある閾値に達するまではハードウェアの障害に影響されず、データの読み書き、運用が正常に行われます。 閾値で許容される障害ノード台数がサイトのノード数以上であればサイト障害にも耐えうる、ということです。 図6. IBM Cloud Object Storageの基本的なアーキテクチャー IBM Cloud 上でもこの ICOS を使った月額課金のオブジェクトストレージを提供していますが、アジア圏の場合、東京・ソウル・香港の3箇所に分散して ICOS を運用しております。 図7. IBM Cloud のオブジェクトストレージ(ICOS) このような3箇所ないしそれ以上の拠点に暗号化したデータを分散しておくことで、セキュアで信頼性の高いデータ保管が可能となり、現実に ICOS に保管されたデータの信頼性は最大 15ナイン(99.9999999999999%)とも言われています。 安い容量単価でデータの最後の砦としての信頼性を確保できるストレージとして、ICOS はテープと違った面で適していると言えます。 また ICOS は API でやりとりするという点でも、昨今の Cloud Native なアプリケーションとも相性が良く、AI や Analytics系でのデータ提供にも非常に適しています。 よって、非構造化データのような保管がメインで利活用の可能性が高いデータに最適な選択と言えるのが、IBM Cloud Object Storage です。 ICOS にはデータのライフサイクルを管理する上で重要な機能があります。 WORM という言葉をご存知でしょうか? 元々は US で決められた法律に準拠したデータ保管のメディア方式の一つです。Write Once Read Many の略で、要は上書きが出来ず、改竄不能なメディアとして出来たものです。 ICOS にもこの WORM の機能があります。 WORM として設定されたエリア(一般的にはバケットにあたる。IBM では Vault と呼んでいる)にひとたびデータを書き込むと、そのデータは消去もできなければ改竄もできなくなります。データ保管の期間を設定することができるので、データライフが終わった時にタイムリーにデータを削除することも可能となります。 例えば、法律や規定等で保管年数を決められている契約書などの書類や、証拠物件として扱われる写真や帳簿類など、普段はアクセスすることもないが無くしてはいけない重要なデータのライフ管理には有効な手段となります。 また、最近はランサムウェアなどのデータ改竄(暗号化)に耐えうるバックアップデータエリアとしても注目されています。   IBM Spectrum Discover ここまでに示した通り、データはますます伸び率が高くなってきています。日ごとに増えるデータを扱う上でネックになるのが、データの特定等、保管データを後から扱うときの仕組みです。 最近のトレンドとしては、ファイルに関連づけられたメタデータや、ユーザーが自由に付加できるタグを活用しデータをカテゴライズしたり検索したり、といった作業が多くなっています。 IBM Spectrum Discover は、こういったメタデータ、タグデータをマネージするためのソフトウェアです。 明確には SDS というわけではなく、むしろデータマネージメントの意味合いが強いソフトウェアです。Discover の強みは、API を介して AI などにデータを食わせることができる、という点にあります。 例えば、画像データであれば画像解析の機能を持った AI(IBM では Watson Visual Recognition がこれに当たる)で画像に付随する情報を抽出し、これをタグデータとして付加する、といった作業を半自動的に行えることです。これにより、膨大なデータのカタログ化や一部のデータの抽出、あるいは不要であったりおかしなデータが紛れ込んでいないかなど、ガバナンスに対応することが可能です。 こうしたデータの利活用の方法も、大きな意味でデータのライフサイクルを支える新しい手法と考えられ、データマネージメントに寄与することができるわけです。 図8. IBM Spectrum Discover のデータマネージメントのイメージ     次回はデータを守ることについてお届けします。最後までお読みいただきありがとうございました。     この記事に関するお問合せ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは、「こちら」からお願いします。   参考ページ IBMストレージ製品 全包囲網。。。最新 IBMストレージ 概要 OpenShiftに代表されるコンテナ環境へのIBMストレージの対応 ハイブリッド/マルチクラウド時代だからこそIBMのストレージ AI導入はどこまで現実的? 5大ハードルとその解決策を解説 普及が進む、機械学習による異常検知。導入の課題はここまで解決している (IBMサイト) データ・ファーストのハイブリッドクラウド基盤を実現するIBMストレージ (IBMサイト) ハイブリッドクラウドにおけるデータ連携の鍵を握るもの

2020年11月09日

最新のデータライフサイクル管理とは?(前編)

IBM の岡田です。 少し間が空きましたが、前回のハイブリッド/マルチクラウド時代だからこそIBMのストレージ は盛り沢山で機能豊富なブロックストレージを中心にクラウド連携のお話をさせていただきまいしたので、少々お腹いっぱいだったかもしれませんね。 今回はデータのライフサイクルを考えていくことで「ファイルストレージ」「オブジェクトストレージ」を前編/後編の2回でお話しさせていただきます。 データの価値 少々古いデータになりますが、以下は時間とともにデータの価値がどう変化するか、ということを示したグラフです。 「Development Code」のように多少の例外はありますが、多くは作られた直後のデータ価値が高く、時間とともにその価値は失われていくという傾向があります。 例外と言いましたが「Development Code」については以下ように解釈できます。 初期は完成に至ってないためコード価値は低く、実際に完成品となって初めてその価値が高くなる。そして製品のライフとともにコード価値が失われていくという意味において、コードの完成時をタイムゼロとみれば、他のデータとも同じ価値の変化を示すと考えられなくもないです。 これをもう少し概念的に捉えたものが次の図です。 図2. データの時間的価値変化のモデル 図に書かれたように、これらのデータにはその時の価値にふさわしい保管場所というものがあります。おそらくみなさんも切羽詰まった時、例えるならば PC のハードディスクがいっぱいになってしまった時など、慌てて古いファイル類を安価な記憶媒である DVD、BD、USB接続の外部記憶装置などに退避したり、使わないファイルを消去したりするのではないでしょうか? 企業で取り扱う大量のデータでは、使わなくなったデータの保管にマッチした記憶デバイスへの移動をタイムリーに実施しないと、無意味に高価な保存スペースを浪費し、多くの無駄が発生します。 このようなことが無いよう、適切にデータのライフに合わせて保管場所を管理する必要があります。以前は、図3左側のように人手でこのような管理を行っていました。これでは手間がかかるだけでなく、ミスが生じてデータを消してしまったり、保管場所がわからなくなってしまうなど多くの不具合が生じる原因にもなりかねません。 このような手間をなくし、自動的に階層管理ができるのが、IBM Spectrum Scale です。 図3. データの階層化管理・今昔   IBM Spectrum Scaleとは IBM Spectrum Scale は、IBM が1990年代に開発した GPFS(General Parallel File System)と呼ばれる科学計算向けの高速ファイルシステムをベースに長年かけて熟成させたソフトウェア・デファインド・ストレージ製品です。 当初は AIX用に使われており、複数サーバーから同一ファイルへの同時アクセス可能とした当時としては先進的なファイルシステムで、特にグリッド系の処理に役立つものでした。 これをベースに様々な機能が付け加えられ、今日ではサーバーからアクセスしやすい NFS や SMB などの標準的なプロトコルに加え、HDFS にも対応した多目的使用に耐えうるものになっています。 この IBM Spectrum Scale には、図4に示す通り多くのハイパフォーマンス・ストレージに根ざした技術があり、また名前が示す通りスケールアウトすることで、より高速、より大容量を扱うことができるようなソリューションです。 現在では多くのスーパーコンピュータやハイパフォーマンスコンピューティングの分野で活用されています。 図4. IBM Spectrum Scale 全容 このように多くの機能がある中、当ブログではあえて自動階層化という機能に焦点を当ててお話をします。 Spectrum Scale は管理下に種類の異なる媒体を複数持つことができます。 この機能の例として、図5のように高価で高速な Flash系のストレージ、速度より容量重視の HDD、そしてテープ装置などで構成されたファイルシステムを見ていきましょう。 図5. IBM Spectrum Scale の自動階層化機能 これらの自動化にはどのように階層管理するかのルールが必要となります。配置ポリシー、移行ポリシーというのがそれにあたります。 配置ポリシーは、ファイルを書き込む際に何を基準にどの媒体・どの位置に書き込むかなどのルールを決めたものです。移行ポリシーは、すでに保管されているファイルがどのような条件で移動し、その際どの媒体・どの位置に移動させるかを決めるものです。 例えば、図5では、初期保管時にはフラッシュに書き込まれます。 次に保管期間が1ヶ月を過ぎると自動的に HDD に移動されます。この時ユーザーから見たファイルの位置は変わっておらず、書き込んだ時のフォルダーにそのまま存在して見えます。 さらに3ヶ月が過ぎるとフォルダーにスタブと呼ばれるリンクポインターのみを残し、ファイル本体はテープに移行されれます。ひとたびこのスタブにアクセスが生じると、ファイルはテープから書き戻され、また3ヶ月後にはスタブのみ残して元に戻ります。 というような、ファイルの価値にふさわしい媒体への移動を自動的に行うことで高価なデバイスの容量を減らすことができ、最終的にテープなどの安価なデバイスで管理することが可能となります。これにより、旬なデータの I/O パフォーマンスを損なうことなくストレージ全体のコストを減らすことにもつながります。 自動階層化の最終層には、テープの他にも、パブリッククラウド上のオブジェクトストレージなども有効です。こうすることで手元の余計な資産を減らすことにも繋がります。もちろんオンプレミスのオブジェクトストレージでも安価な容量単価を実現することができます。 「最新のデータライフサイクル管理とは(後編)」にて、そのオブジェクトストレージの IBM製品、IBM Cloud Object Storage のお話をしましょう。   最後までお読みいただきありがとうございました。   この記事に関するお問合せ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは、「こちら」からお願いします。   参考ページ IBMストレージ製品 全包囲網。。。最新 IBMストレージ 概要 OpenShiftに代表されるコンテナ環境へのIBMストレージの対応 ハイブリッド/マルチクラウド時代だからこそIBMのストレージ AI導入はどこまで現実的? 5大ハードルとその解決策を解説 普及が進む、機械学習による異常検知。導入の課題はここまで解決している (IBMサイト) データ・ファーストのハイブリッドクラウド基盤を実現するIBMストレージ (IBMサイト) ハイブリッドクラウドにおけるデータ連携の鍵を握るもの

2020年10月26日

システム連携とは?代表的な方法や課題について解説

ERP、SFAツール、顧客管理システム、POSシステム… 今日では、様々なシステムを活用してビジネスを展開することが当たり前となりました。 さらにそれぞれのシステムを必要に応じて連携して利用することによって、組織全体として、システムやデータをより有効に活用していくことができます。 そこで本コラムでは、システム連携の代表的な手法や課題などを解説していきます。   システム連携とは? かつて、システムは一部の大企業だけのものであり、大型のメインフレームの導入が主流でした。 しかし、1990年代以降にダウンサイジングの波が押し寄せ、今日では大企業だけではなく、幅広い規模・業種の企業が業務別・目的別に最適化された多種多様なシステムを導入しています。 こうした中で、すでに多くの企業が取り組み始めているのがシステム連携です。システム連携とは、異なるシステム間でデータを相互に共有・処理できるようにすることを言います。 システム連携を行うことで、システム間で分断されていたデータを連携して活用することが可能となり、私たちはより深い洞察を得たり、オペレーションミスを減らしたりといった効果を得ることができます。 例えば、SFA(Sales Force Automation/営業支援)ツールと MA(Marketing Automation)ツールを連携することで、営業担当者やマーケティング担当者は、見込み客の獲得から最終的な受注に至るプロセスを俯瞰的に把握できるようになります。 その結果、マーケティング担当者はウェブサイトの流入数や見込み客の獲得数だけではなく、アポイントメント獲得数や最終的な受注数といった営業側の指標も見ながら、マーケティング施策の検証や効果改善に向けて精度の高い施策検討を行うことができます。 また、勤怠管理システムと給与計算システムを連携すれば、勤務時間に応じた毎月の給与計算を自動化することができるため、Excel での集計など人による作業工数の削減に加え、勤務時間管理や給与計算でありがちな入力ミスや計算ミスといったオペレーションミスの防止につながります。 次項でシステム連携を実現するための具体的な方法を解説していきます。   システム連携の代表的な方法 現在よく使われているシステム連携の代表的な方法は、以下の3つです。 ファイル転送 メッセージキュー API それぞれについて解説します。   1. ファイル転送 ファイル転送は、ファイル単位で1対1でのシステム連携を実現する方法です。長年にわたってシステム連携の代表的な手段として利用されてきました。 ファイル転送は、FTP(File Transfer Protocol)、SMB(Server Message Block)、CIFS(Common Internet File System)といったプロトコルを用いて実現します。 このうち、FTP はファイル転送で利用される代表的なプロトコルの1つです。後述する方法に比べ、大容量データを高速でやり取りすることができるという利点があります。 データ連携は通信プロトコルである FTP を通じて行うので、連携するシステムそのもののプログラムに手を加える必要がありません。そのため、一方のシステムで障害が発生しても、もう一方のシステムに及ぶ影響範囲を限定することができます。 一方で、ファイル転送でシステム連携を実現する際にはファイルの静止点(※1)が必要になります。 ファイル転送はデータを一括して転送するバッチ処理によって行われるので、全データの処理が完了しなければ結果がわからず、途中経過を把握することができません。そのため、リアルタイム処理に近い形でスピーディに結果を知りたいという場合には、1回のデータ量を減らして転送時間を短くする、といった工夫が必要になります。 ※1:ファイル内のデータが更新されていない状態のこと   2.メッセージキュー メッセージキュー(Message Queue)は、メッセージ単位で N対1、または N対N でのシステム連携を実現する方法です。 送信側が送信したメッセージは、受信側が取り出すまでキューと呼ばれるデータ領域に保管されます。キューは、メッセージ指向ミドルウェア(MOM:Message Oriented Middleware)やメッセージブローカー(Message Broker)で管理するのが一般的です。 送信側の処理は、キューにメッセージを送信することで完了します。 直接受信側にデータが送信されるわけではないので、受信側のシステムの負荷やリソースなどを意識する必要はありません。受信側でシステムダウンが発生していたりリソースが逼迫していたりしても、送信側は処理の完了を待つ必要がないのです。そのため、送信側が意図したメッセージの順序を維持することができる、というメリットがあります。 このような特性から、メッセージキューは非同期処理が必要なシステム連携に向いています。   3.API API(Application Programming Interface)は、HTTP あるいは HTTPS 形式で実装されることが多い N対1 でのシステム連携を実現する方法です。 API は、システムの外部仕様を定義して各機能を利用するためのインターフェースを提供するものです。 そのため、多くの場合 API は、システムを構築する言語と同じ言語のライブラリと通信プロトコルで提供されます。 API を使用すると、そのシステムの実装方法を知らなくても他のシステムと連携させることができます。Webアプリケーションの特定の機能のみ API として実装して公開することで、社外の一般ユーザーが利用できるようにするといったことが可能になります。 例えば、下図のように社外の一般ユーザー向けに自社の Webサーバー上にある Webアプリケーションを提供した上で、ゲートウェイ上でアクセス制御を行うことで、セキュリティを担保することができます。   幅広いシステム連携方法に対応するのはコストがかさみ、 手間も増える… 前項で紹介したように、一口にシステム連携といっても様々な方法が存在します。そして、連携するシステムの仕様、やり取りするデータ量、データ形式などによって、採用するべきシステム連携の方法は異なります。 例えば、CADデータをやり取りするといったようにシステム間で大容量データを送受信する場合には、FTP によるファイル転送が適しています。 一方で、SaaS型ソリューションの多くが API を公開しているように、顧客や取引先といった外部のユーザーが任意に特定のシステムと連携するための方法を提供したい、という場合には API が適しています。従来のように個別にシステム連携のプログラムを開発することなく、ユーザー側で連携作業を完了できるからです。 しかし、用途に合わせて複数のシステム連携の方法に対応するとなると、複数のソリューションを導入しなければなりません。それでは、製品毎のライセンス・導入コストがかさんでしまいます。 また、利用するソリューションが多くなると個別に管理・運用をする必要があるため、運用管理の手間も煩雑化してしまいがちです。実情として、用途に応じてシステム連携の方法を使い分けるのはハードルが高いと言えます。 一方、最近では様々なシステム連携の方法を統合的に運用管理できるプラットフォームが登場しています。   用途・目的に合ったシステム連携の方法を選べる 統合プラットフォーム「IBM Cloud Pak for Integration」 「IBM Cloud Pak for Integration」は、IBM が提供している MQ(メッセージキュー)、App Connect(アプリケーション連携)、API Connect/DataPower(API連携)、Aspera(ファイル転送)といったシステム連携を実現する様々なソリューションを統合したプラットフォームで、システム連携をワンストップで実現することが可能です。 また「IBM Cloud Pak for Integration」 は、実績のある Red Hat OpenShift Container Platformで稼働し、コンテナ技術に最適化しているので、オンプレ、IBM Cloud、他社クラウドなど様々な環境にデプロイできます。 システム連携に課題を感じているという方は、ぜひ、「IBM Cloud Pak for Integration」についてお問い合わせください。     この記事に関するお問合せ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは、「こちら」からお願いします。   参考情報 (製品情報)IBM Cloud Pak for Integration 全ての企業が AI カンパニーになる!「IBM THINK Digital 2020」に参加した IBM Cloud Paks シリーズ ご紹介資料 【資料】IBM Cloud Pak for Integration ご紹介 (IBM サイト)IBMデモ Cloud Pak for Integration 今、デジタルサービスに求められる必須要件とは!?アプリケーションのコンテナ化で得られる5つのメリット 【やってみた】IBM Cloud Pak for Applications導入してみた:概要編

2020年09月30日

DRで考えるべきITシステム復旧の3つの指標と、実現方法を解説。BCPとの違いは?効率的な対策は?

近年、大規模な自然災害が増加していることから DR の重要性が高まっています。 DR は「Disaster Recovery」の略であり、文字どおり「災害時にどう復旧するか」という対策を指します。 ひと言で「災害からの復旧」と言っても対策は多岐にわたり、求める対策のレベルによって運用にかかるコストにも違いがあります。どこまで対策をすればいいのか、悩む企業も多いのではないでしょうか。 今、改めて押さえておきたい DR の基本・指標と、実現するための方法について解説します。   DRの基本と、BCPとの違い DR は、地震や台風などの自然災害などが発生した際にシステムをスムーズに復旧させるための対策のことです。 似たものとして「BCP(事業継続計画)」があり、どちらも緊急事態への対策を検討するものですが、BCP が事業全般を継続するための計画を策定するのに対し、DR は「システムを災害発生から復旧させること」に重点を置いています。特に、自社オフィスやデータセンターなどが台風や地震といった災害により物理的に利用できなくなってしまった際に、どう復旧するかがポイントとなります。   DRで最初に検討すべき3つの指標 DR 対策を検討する場合は、システムを「いつまでに」「どの状態に」復旧すればよいのかをしっかり定めましょう。その際に、指標となるのが下記の3つです。 RTO(Recovery Time Objective/目標復旧時間) 「いつまでに、システムを復旧すればよいか」の目標を定めた指標 RPO(Recovery Point Objective/目標復旧時点) 「いつのデータに、復旧できればよいか」の目標を定めた指標 RLO(Recovery Level Objective/目標復旧レベル) 「処理能力や品質などをどのレベルまで、復旧できればよいか」の目標を定めた指標 これらの指標は、例えば「災害発生から3日以内に(RTO)」「前日のデータで(RPO)」「通常の半数程度の処理に対応できる(RLO)」ように復旧する、といった形で目標を定めることを指します。 これらの指標を組み合わせて対策を検討することになりますが、その方法は「バックアップの頻度」「復旧方法(手動/自動など)」により大きく5つのレベルに分けられます。 レベル1:スタンバイなし/バックアップリストア(手動) レベル2:コールドスタンバイ/バックアップリストア(手動) レベル3:コールドスタンバイ/プログラムによるバッチコピー レベル4:ホットスタンバイ/ツールによる非同期コピー レベル5:ホットスタンバイ/ツールによるリアルタイムコピー レベルが上がるにつれ RPO・RTO を短くでき、システムダウンの時間を最小限に抑えられますが、コストも高くなります。すべてのシステムを高いレベルで運用すればよいわけではなく、システムごとに指標を定めどのレベルで運用するかを検討することが重要です。 例えば「更新頻度の低い、社内の人事データ」であれば、リアルタイムに同期をとる必要はなく、月1回のバックアップデータを別拠点に保存する形で十分対応できるかもしれません。一方「ECサイトの受注データ」は前日のデータが残っていても不十分で、極力 RPO・RTO を短くする対策が必要になります。 どのシステムをどこまで対策するのか、コストとのバランスを見ながら検討すべきでしょう。   DRを実現する3つの方法 次に、こういった DR 対策を具体的に実現する方法を解説します。DR では、大きく3つの方法が挙げられます。 バックアップメディアを遠隔地に保管 バックアップデータを保存したメディアを遠隔拠点に運搬することで、データを守ります。メディアの種類も様々ですが、大容量データを長期保管する場合などは、比較的コストを抑えられるテープメディアが有効です。 ネットワークを介した遠隔バックアップ、リストア ネットワークを経由し、クラウド(IaaS)や別拠点にバックアップデータを保存します。災害時には、バックアップ環境側で新たに環境を構築・リストアすることで、早期復旧が可能になります。 データレプリケーション データを2拠点間でリアルタイムに同期し、障害発生時には、フェイルオーバーすることでダウンタイムを最小限に留めることができます。レプリケーション先でも本番環境と同等の環境が必要になるため、コストが割高になる傾向があります。 上記のうちどの方法が適しているのか、バックアップ先はクラウド・オンプレミスのどちらがいいのか、などは企業によって異なります。また、つい「データをどこにバックアップするか」ばかり考えがちですが、データだけバックアップしてもアプリケーションなど含めたシステム環境が揃わなければ、業務で利用できるようにはなりません。 復旧時の手順や環境まで含めて、あらかじめ確認しておきましょう。   バックアップ製品などをうまく活用し、効率的なDR対策を DR は運用コストなどを理由に二の足を踏む企業も少なくありませんが、ビジネスにおいてシステムやデータの重要度が高まり続けるなか、データを失うリスクを考えれば、コストをかける価値は大きいはずです。 DR 対策で活用するバックアップなどの製品は数多く登場していますが、特にネットワークを介したバックアップを行う場合は、データの転送効率も要チェック。 例えば、IBM Spectrum Protect は、「永久増分」という方法を採用し、転送するデータを最小限に留めます。さらに高速転送機能により、WAN 環境でも高品質回線並みの転送速度を実現します。 いざという時に、想定よりもバックアップ環境でリストアして利用できるまでに時間がかかり、大きな機会損失になった、なんていう事態を防ぐには最適なツールです。 DR 対策で大切なことは、保有するデータごとに自社の事業内容と優先度に合った環境を用意しておくことです。前述のとおり、3つの指標<RTO・RPO・RLO>を策定した上で、効率的な DR 対策を目指しましょう。     この記事に関するお問合せ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは、「こちら」からお願いします。   参考情報 IBM Spectrum Archive IBM Spectrum Virtualize for Public Cloud IBM Spectrum Protect IBM Spectrum Protect Plus 今、BCPで求められるITシステム対策について解説。考えるべき基本は?最優先すべきポイントは?

2020年09月30日

今、BCPで求められるITシステム対策について解説。考えるべき基本は?最優先すべきポイントは?

災害など緊急事態における対策を定める「BCP」。新型コロナウイルスの感染拡大もあり、今、改めて注目を集めています。 ですが、「なんとなくわかっているけれど、システムごとに最適な対策をできているかは自信がない」「きちんと対策できているか不安」という企業も多いのではないでしょうか? また、従来の自然災害やパンデミックは比較的短期間で収束することを想定していましたが、予想を超える大雨の頻発、さらに新型コロナウイルス感染も収束の兆しが見えず問題が長期化するなか、BCP 対策に求められるものも大きく変化しています。 では具体的にどうすればよいのか、BCP の基本から、今、企業がすべきことを解説します。   BCPの基本とは?策定までに検討すべきポイント BCP とは、Business Continuity Plan(事業継続計画)の略であり、自然災害やテロなどの緊急事態において、事業を継続するための方法などを取り決めた計画を指します。つまり、通常のオフィスやシステムが利用できない事態に陥っても、素早く体制を復旧し事業を続けるためにあらかじめ具体的な計画を定めておく、ということです。 事業継続と言っても、緊急事態ですからすべて通常と同じように復旧できるとは限りません。どの業務を優先して継続すべきかを判断し、体制を整えるのが基本。まずは以下の流れで検討し、BCP 策定を目指しましょう。 優先すべき中核事業や、ビジネスに影響が大きい業務を特定する 上記、事業・業務の目標復旧時間を決める 事業を継続するための代替案を用意する BCP を発動する基準や、体制を明確にする 具体的な対策が社会情勢や事業の変化によって変わっても、この基本は変わりません。自社が守るべき事業や業務をきちんと見極めることが大切です。   BCP対策におけるシステムの役割 BCP で検討すべきことは、オフィスや工場・店舗など “場所” の確保、取引先との連携、顧客へのフォローなど多岐に渡りますが、システムが担う役割も大きくなります。「業務システムをどう継続するか」「オフィスに出社できないなかで従業員と、どう連絡をとるのか」といった観点のほか、緊急時に在宅勤務できる体制の整備も必要になるでしょう。 特に、コロナ禍により緊急事態が長期化するなか、対策すべき範囲が拡大しています。 在宅勤務では、オフィスのファイルサーバなどにアクセスできないといった課題が浮き彫りになり、クラウド化を進める企業も増加。緊急避難的な対策に留まらず、業務プロセス自体の効率化やモバイル端末活用推進、さらにはオンライン研修など、根本的な見直しを行うケースも今後増えると予想されます。 しかし、これだけのことを一気に進めるのは難しいでしょう。こちらも優先度をつけ、順次進めることをお勧めします。 なかでも最初にやっておきたいのが、「データ保全」です。災害であれパンデミックであれ、データがなくなってしまっては事業の復旧・継続は困難になります。 データを異なる拠点やクラウドなどに保管し、万が一の事態にも損なわれないよう備えることが、BCP において基本中の基本と言えるでしょう。   BCP観点で有効な「データ保全」の方法 データ保全の方法は様々ですが、「事業を継続する」という観点からはデータやシステムの情報を異なる場所で同期する「レプリケーション」が有効です。 レプリケーションでは、決まった時刻のバックアップデータを取得・保管するのではなく最新の情報をリアルタイムに同期するため、本番環境が利用できなくなった際にはフェイルオーバーすることで即座にレプリケーション先の環境に切り替えることが可能。これにより、データを複数個所で保存しながら、ダウンタイムを最小限にしてシステムを利用し続けることができます。 レプリケーション先はクラウド(IaaS)も有力候補にはなりますが、セキュリティなどの観点からオンプレミスの拠点同士で構成するケースも。例えば、東京と大阪の拠点間でレプリケーションすれば、災害時の対策としても十分有効です。 どこにレプリケーションするのがベストなのか、自社の状況やシステムの規模などを踏まえて検討しましょう。 もう1つ、レプリケーションを実現する製品を選ぶ際には、データ圧縮や転送速度などの基本スペックとあわせて緊急時における対応のしやすさも確認することをお勧めします。 ストレージ自体にレプリケーション機能を搭載するものもありますが、この場合、製品ごとにツールを使い分ける必要があります。「IBM Spectrum Virtualize」は、外部ストレージ仮想化機能を提供します。「IBM FlashSystem」や「IBM SAN Volume Controller」に搭載することで、異なるベンダのストレージを一括管理することが可能です。 IBM Spectrum Virtualize は、異なるベンダのストレージも一元的にレプリケーションでき、復旧時にもまとめて対処できるのでスムーズです。 BCP は、「一度考えたらOK」というものではありません。社会情勢の変化だけでなく、自社の中核事業や業務が変わることもあるでしょう。 ですが、そのなかでもデータを守る仕組みは不可欠。基盤となるデータ保全を確実に行いつつ、随時対策を見直し、適切な計画を検討する姿勢こそが重要です。 BCP 対策の第一歩として、IBM Spectrum Virtualize などを活用したデータ保全対策を整備しておくことをお勧めします。     この記事に関するお問合せ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは、「こちら」からお願いします。   参考情報 IBM Spectrum Archive IBM Spectrum Virtualize for Public Cloud IBM Spectrum Protect IBM Spectrum Protect Plus DRで考えるべきITシステム復旧の3つの指標と、実現方法を解説。BCPとの違いは?効率的な対策は?

1 2 3 4 5 15
back to top