特集・ブログ

全て

2020年12月28日

データを守るということについて

IBM の岡田です。 いよいよシリーズ物、最後のテーマまでやってきました。 ここまでの内容はいかがでしたでしょうか?もう少しで完結しますので、最後までお付き合いいただければと思います。 さて、今回のテーマは「データを守ることについて」ということで、様々な脅威からどうやってデータを守るか、という内容でお届けします。   データを脅かす脅威とは 一昔前までは、データの脅威といえば人為的オペミス、装置の故障・障害、災害などが挙げられてました。しかし、最近はこれに加えサイバー攻撃といったものも加わってきております。 今まではサイバー攻撃というと、ネットワークあるいはサーバーにて対処すべきもの、という考え方が主流だったかと思います。これらはサイバーセキュリティという範疇の対策であり、今までも多くの製品やサービスによって培われてきた技術です。 しかし、昨今のサイバー攻撃はマルウェアが主流となっており、特にランサムウェアと呼ばれる攻撃が世間的にも目立ち始めてます。企業のデータを強制的に暗号化し解除するための身代金を要求するというものです。 確か最近ニュースで、日本での被害のとんでもない状況を目にした覚えがあります。調査対象の半数以上の企業は攻撃を受けた経験を持ち、実際に身代金を払った会社も調査対象の約3分の1あったということ、また、本当に支払われた身代金も平均が億を優に超える金額だったことに筆者も驚きました。 ということで、今回はストレージ技術にできるデータの保全について、従来の物理的な脅威から守ること、今日のサイバー攻撃から守ることの2つに分けてお話していきます。   物理的な脅威からデータを守る 止まらないシステムを構築するために、IT の世界では様々な対策が体系化し今日に至ってます。 全ての ITインフラを成す要素を冗長化するといったものはごく当たり前で、IT技術者なら必ず取っている対策ですね。機器自体も各パーツが冗長化されいつでもホットスワップでパーツ交換できるような仕組みになっているのが現在の IT機器です。 このように、シングルポイントになり得る構成をできる限り排除することで物理的な機器の障害や故障からシステムを守る、というのが今時当たり前のシステム設計なのはご存知の通りです。 データについてはどうでしょう。 システム構成の一部としてデータの通り道も冗長化されているのが昨今の設計ですが、データを貯める場所、つまりストレージについては過去より多くの技術が使われてきております。 パーツとしての HDD 等に用いられる磁気ディスクの盤面に書き込む際のフォーマットについては、ECC(Error Check and Correction)と呼ばれる技術、すなわちデータをビット化けや傷・汚れなどによるディスク上の脱落から計算により正しいデータを導くテクノロジーが用いられております。 さらに上のレイヤーでは、HDD や SSD などデイバイスの故障に対応するために、RAID といった技術が使われていることも多くの IT技術者はご存知でしょう。 最近は大容量下での再構成の長時間化などを改善するため、各社独自の RAID技術を駆使していたり、イレージャーコーディングといった、今まではディスク盤面などミクロな世界で行われていたような ECC をベースとした考え方を、装置・筐体といったレベルまで広げた技術などが使われ始めています。 最近のストレージ装置はユーザーに開放している論理ボリュームに対して、そのコピーを複数個筐体内に取って世代管理することもありますし、筐体間レプリケーションで別の安全な場所にコピーを取るということもできます。 そして、昔からあるオーソドックスな方法としては、ある時点のデータを静的に固めて安全な媒体に書き出して取っておく、所謂、バックアップが一番一般的ではないでしょうか? しかし、実はバックアップ技術も1990年代のような、ただテープ媒体などに静的データを単純にとれば良いという時代はとっくに終わっており、今やバックアップ先データ容量を極限まで抑える技術であったり、転送を効率的に行う技術であったり、いろいろな技術が併用されております。 少し簡単に紹介しましょう。以下にご紹介するのは IBM Spectrum Protect と呼ばれるバックアップソフトで使われている技術です。   1. 永久増分バックアップ 初回バックアップのみフルバックアップを取り、その後のバックアップは増分(差分)のみ。 こうすることでバックアップ先データに必要な容量を格段に節約することができますし、このデータを遠隔にレプリケーションする際もデータ量が少ないため、ネットワークに余計な負担をかけずに済みます。 図1. 永久増分バックアップ   2. 重複排除・圧縮技術 すでに枯れた技術で、ストレージ装置にも使われているものですが、特に重複排除については過去のバックアップデータとの重複もあるので、さらに効果が見込まれます。 また、VM などの仮想環境でも似たディスクイメージを扱うことで、重複排除率は格段に上がります。 図2. 重複排除   3. FASP技術 バックアップデータを DR 目的で遠隔に飛ばす際には、ネットワーク帯域を通常の TCP/IP より効率的に使用できる FASP(Fast Adaptive Secure Protocol)により、高速転送が可能となります。 図3. FASP転送   4. 今時のバックアップ先ストレージ バックアップのとり先といえば、昔はテープ、そしてディスクの時代があり、最近はまたテープが見直されてきています。 理由はもちろんビット単価であったり可搬性であったりが主ですが、後述するサイバー攻撃対策としても最近は注目されています。 最新技術活用という点では、クラウドのオブジェクトストレージにバックアップするというのも出てきています。その基本的な3形態を示したのが次の図です。 図4. バックアップ3形態   悪意のあるサイバー攻撃からデータを守る ここまでは、レガシーな考え方、つまり物理的な脅威への対策としての最新のバックアップ技術です。 ところが昨今はこう言った脅威のみならず、意図的なデータ破壊や改竄への脅威、つまりサイバー攻撃への対策というものが必要になってきています。 そもそも色々な技術の蓄積で現在のサイバーセキュリティ成り立っていますが、攻撃者とのいたちごっこであることは否めません。したがって、突破された際の対策というものも必要になります。 最近のデータによると、実際にハッカーあるいはマルウェア等に侵入されたことが発覚するまでの日数は数百日とも言われており、わかった時にはすでに多くのデータの破壊・改竄・漏洩がなされた後、ということになりかねません。 このうち、破壊・改竄はデータが失われる訳で、データを使った企業活動ができなくなるという致命的な結果になり得ます。ゆえに、破壊・改竄(ランサムウェアによる強制的暗号化も含む)への対策が必要となるわけです。 図5. サイバー攻撃の際、データが役に立たなくなる 多くの場合、ネットワーク越しにサイバー攻撃が行われます。つまり、バックアップがあるから大丈夫と思っていても同じネットワーク内にあれば同様に犯された使えないバックアップデータとなる可能性が出てきます。 そこで、覚えていただきたいキーワードがあります「エアギャップ」と「イミュータブル」。 サイバーレジリエンシーの基本的な考え方です。 図6. エアギャップ・イミュータブル 前者は、ネットワーク的なつながりのない場所・物・仕組みを指し、後者は、改竄できない場所・物・仕組みをさしています。 つまり、バックアップなどの最後の砦となりうるデータは、こういったエアギャップ対応、あるいはイミュータブル対応のなされたメディア・機器・場所・仕組みなどに置くことで、初めてサイバー攻撃からデータを守るということができるわけです。 もちろん RPO がゼロになるわけではないので失うものも若干ありますが、億単位の身代金を支払うことからは救われます。 RPO をゼロに近くするためには当然、検知能力を上げる他ありません。 サイバーセキュリティで 100%検知できればこのような不幸は起こりませんが、万一気づかずネットワーク内に攻撃が入ってしまった場合も、データ側の仕組みで検知することもできるかもしれません。以下に二つの検知技術を紹介します。 図7. IBM Spectrum Protect の検知機能 こちらは、定常状態と大きなデータの変化のあった状態との差からサイバー攻撃の可能性の有無をチェックする機構です。 データが暗号化されたり破壊されたりすると、直前のバックアップデータとは大きく異なるデータとなるため、当然の事ながら重複排除率は極端に低くなります。さらに、圧縮率やファイルの増加数など、定常時とは異なる変化が現れるでしょう。 そういった変化を検知することで、データに何か大きな変化があったこと、すなわち破壊・改竄の可能性をいち早く検知することができるわけです。 次に、例えば IBM の Spectrum Scale には File Audit Logging という機能があります。 これをサイバーセキュリティの仕組みで検知系に繋げてあげれば、いち早くおかしなデータから本番データを守ることができるわけです。 図8. IBM Spectrum ScaleとQradar によるサイバー攻撃の検知   サーバー攻撃と対策のいたちごっこは、これからも続いていくでしょう。 しかし、アンチウィルス系の対策のようにウィルス自体のシグネーチャーやパターンに頼った対策は、必ず後手となります。そういう意味で、定常状態との変化で検知する方法は非常に有効な手段かと思われます。 ぜひ有効な対策を打って、備えを万全にしていきましょう!   約半年にわたってブログを書かせていただきましたが、少しでも IT を担う皆様にお役に立つことができると幸いです。 ありがとうございました!     この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ   参考ページ IBMストレージ製品 (製品情報) 全包囲網。。。最新 IBMストレージ 概要 (ブログ) OpenShiftに代表されるコンテナ環境へのIBMストレージの対応 (ブログ) ハイブリッド/マルチクラウド時代だからこそIBMのストレージ (ブログ) AI導入はどこまで現実的? 5大ハードルとその解決策を解説 (ホワイトペーパー) 普及が進む、機械学習による異常検知。導入の課題はここまで解決している (コラム) データ・ファーストのハイブリッドクラウド基盤を実現するIBMストレージ (IBMサイト) ハイブリッドクラウドにおけるデータ連携の鍵を握るもの (IBMサイト)   .btn_B{ height:25px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_B a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }  

2020年12月25日

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

数年前からその高速性が注目を集めていたオールフラッシュストレージですが、ここにきて大きく市場が伸びています。 以前は、特に高速な処理が必要なデータベースなどの特定用途に導入されるケースが多く見られましたが、SSD の低価格化とともに、より汎用的な用途で導入されるケースが増加。従来の HDDストレージとポジションが逆転し、「基本的にはオールフラッシュストレージを検討し、バックアップなど容量が大きく、アクセス頻度が少ないものに HDD を利用する」スタイルが一般的になりつつあります。 様々なベンダーがオールフラッシュストレージを展開するなかで、屈指の高いシェアと高い評価を誇るのが「IBM FlashSystem」です。 他製品との比較において、レイテンシ―が低く高速であることが最大の利点。加えて、データ圧縮などによるストレージ基盤の効率化やマルチベンダー・マルチクラウドへの対応…など、魅力の多い IBM FlashSystem について、その特長や活用シーンをまとめて解説します。   Index IBM FlashSystemの2大特長を支える独自技術 エントリーからハイエンドまで、幅広い要件に対応できるラインナップ 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 ストレージ製品 (製品情報) - ストレージ機能のソフトウェア化を実現した SDS製品 (Software Defined Storage) も含め、幅広いラインアップを取りそろえています。 全包囲網。。。最新 IBMストレージ 概要 (ブログ) - 今回は IBM の最新情報を交えつつ、IBM のストレージ製品の概要をご紹介させていただきます。   .btn_B{ height:25px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_B a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }  

2020年12月22日

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

IBM Power で基幹システムを運用する国内企業の多くは、ハードウェアの EOS やシステムを熟知した人材の退職といった課題に頭を悩ませていますが、ここ最近新たな悩みが加わっているようです。 データセンター事業者がビジネスの選択・集中を進めた結果、IBM i や AIX を扱うデータセンターが減少し、行き場を失うケースが増えているのです。 クラウドファーストが既定路線となるなか、コロナ禍も重なりオンプレミス廃止を検討する企業が増えていますが、いまさら自社内にオンプレミス構築することは考えづらい状況です。 こうした企業に向けて、末永く安心して利用し続けられる IBM i や AIX の環境をクラウド型で提供するのが、エヌアイシー・パートナーズ株式会社(以下 NI+C P)の「Cloud Power」です。 以下では、IBM Power をオンプレミスで利用する企業や、こうした企業を支援するパートナー企業にとってのメリット(特長)にフォーカスしつつ、具体的な導入事例についても紹介します。   Index 事業者統合が進むなか、データセンターサービスの選択肢が限定される傾向に 国内企業のニーズに寄り添う人気の IaaS「Cloud Power」 実際の導入事例に見る「Cloud Power」活用シナリオ 再販パートナーと一体になって充実サポートを提供 この記事に関するお問い合わせ 関連情報   事業者統合が進むなか、データセンターサービスの選択肢が 限定される傾向に ここ数年の国内 IaaS/PaaS 市場規模(事業者売上高ベース)は大幅に拡大し、2021年以降も引き続きハイペースで拡大し続けるものと予測されています。直近では、これまで取り残されていた感もあった金融業の勘定系システムや一般企業の基幹系システムについても、クラウド移行を検討するケースが。 一方、データセンター市場においては大手データセンター事業者による中小規模事業者の買収が進み、AWS・Azure・Google Cloud など主要クラウドベンダ向けのハイパースケールデータセンターの開発・運営に資本が集中投下されています。 こうしたメガトレンドのなかで IBM i や AIX のデータセンタービジネスが縮小し、国内企業に影響がおよんでいるというのが、冒頭で解説した事象の背景です。 データセンター事業者のホスティングサービスが利用できなくなることも深刻ですが、オンプレミスで IBM Power の基幹システムを運用している企業にとっても、利用可能なサービスの選択肢が少なくなるという意味で影響は少なくありません。   国内企業のニーズに寄り添う人気の IaaS「Cloud Power」 今後データセンター事業者の統合やサービスの集約がさらに加速すると予測されるなか、IBM Power の基幹システムを運用している国内企業が安心して利用し続けられるクラウド移行先として、「IBM Cloud」を思い浮かべる方もいるかと思います。 2019年の RedHat 買収にともない、Linux や Kubernetes などのオープンソース・テクノロジーで構築されたハイブリッド・クラウド・プラットフォームを提供する IBM Cloud では、IBM i や AIX のプライベート IaaS「IBM Power Virtual Server」を2020年11月より国内で提供開始しています。 北米・ヨーロッパ・オーストラリアにリージョン展開しており、グローバルでビジネスを展開する国内のエンタープライズ企業などにとって有力な選択肢となるでしょう。 そんな中、情報システム部門のリソースが限定されていて導入(環境構築)から運用に至るまできめ細かなサポートを期待する企業には、IBM製品の国内ディストリビューターとして製品に関する豊富なノウハウを有する NI+C P の「Cloud Power」をお勧めします。 同サービスは、グループ親会社である NI+C のデータセンターにて IBM Power を基盤に、IBM i および AIX環境を提供するクラウドサービス(IaaS)で、2009年にサービスを開始。2020年6月現在、75社200区画にてサービス提供しており、ここ1年で70区画が新規導入。 クラウドサービスとして、ハードウェアの保守切れなどを気にすることなく常に最新のハードウェア環境を利用できるほか、以下のようなメリットを導入企業に提供します。   OSアップデートなど、システム基盤の維持・運用はおまかせ オンプレミスで IBM Power を運用する企業にとって、セキュリティ対策や 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 環境の構築・運用で蓄積したノウハウを最大限活かすことができます。 これまでオンプレミス中心で、クラウドならではの扱いに少し不安を感じるというケースでは、NI+C P が一体となり課題に対して1つひとつ対応するので安心して導入いただけます。 Cloud Power の導入検討についてはもちろん、IBM Power基盤をご利用のお客様は、ぜひ、NI+C P にご相談ください。     この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ   関連情報 Cloud Power (製品情報) - IBM i (AS400)、AIX を国内シェアNo.1 のクラウド環境でご提供します! コロナ禍で基幹システムでもクラウド移行が急拡大!の背景を探る (コラム) - クラウド移行を検討する企業に向けて、お勧めのマネージド型クラウドサービスについて紹介します。   .btn_B{ height:25px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_B a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }  

2020年12月03日

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

IBM Cloud Pak for Applicationsの新規販売は終了いたしました。 今後のアプリケーションランタイムソリューションは、2021年1月15日に発表されたWebSphere Hybrid Editionとなります。 現在、日本の多くの企業にとって「2025年の崖」をいかに克服するかが大きな課題となっている中で、レガシーシステムの抱える数々の問題が足かせになっています。 本コラムでは、"企業が抱えるレガシーシステム特有の課題を解決してデジタルトランスフォーメーション(以下:DX)を実現するためには、なぜ新しいアプリケーション開発や既存アプリケーションのモダナイゼーションが必要なのか?" について考察します。   Index DX実現にアプリケーションのモダナイゼーションが必要な理由 モダナイゼーションの事例 アプリケーションのモダナイゼーションを推進する「IBM Cloud Pak for Applications 」 この記事に関するお問い合わせ 関連情報   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 はエヌアイシー・パートナーズが自信をもってお勧めするソリューションです。     この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ   関連情報 今、デジタルサービスに求められる必須要件とは!?アプリケーションのコンテナ化で得られる5つのメリット (コラム) - 今注目されている「コンテナ化」。コンテナ化とは?そのメリットとは? 【やってみた】Cloud Pak for Applications 導入してみた:Cloud Pak for Applications 導入編 (ブログ) - 今回は、AWS 上に構築した Openshift 環境に Cloud Pak for Applications をインストールします! IBM Cloud Paks シリーズ ご紹介資料 (資料) ※会員専用ページ - 6つの Cloud Paks について、お客様の理解度に応じて必要な資料を選択できる形式になっています。   .btn_B{ height:25px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_B a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }  

2020年11月30日

【てくさぽBLOG】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日

【てくさぽBLOG】IBM Cloud Pak for Applicationsを導入してみた(ICP4 Applications導入編)

※IBM Cloud Pak for Applications の新規販売は終了いたしました。今後のアプリケーションランタイムソリューションは、2021年1月15日に発表された「WebSphere Hybrid Edition」となります。 *  *  *  *  *  * こんにちは。てくさぽBLOGメンバーの岡田です。 第1回、第2回に続き、今回は AWS上に構築した Openshift環境に Cloud Pak for Applications(以下 CP4A)をインストールします。 目次 事前準備 インストール実行 2-1.Entitlement Keyの入手 2-2.インストール構成ファイルをインストーライメージから取り出す 2-3.インストーラの実行 2-4.インストール後の確認 つまづいたポイント 最後に お問い合わせ 1.事前準備 環境 Openshift 4.3.22(AWS上にCloudFormationを用いて構築)※構築したOpenshift環境にocコマンドでログインできることを確認 CP4A 4.0.1 用意するもの IBMid Dockerコマンド 17.05以上の実行環境 2.インストール実行 2-1.Entitlement Keyの入手 "MyIBM Container Software Library"にアクセスし、Entitlement Keyをコピー※アクセスすると IBMid でのログインが求められるので 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. Seehttps://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にアクセス ※Cloud Pak Console には OpenShift Webコンソールからもアクセスできます。画面右上の四角形のアイコンをクリックすると "Cloud Pak for Applications - Cloud Pak Console" が確認できます。 以上で CP4A のインストールは完了です! 3.つまづいたポイント インストールがエラーで完了しない… 作業当初は、OpenShift4.2.23 上にてインストールを開始しました。 「チェックコマンドの実行」までは正常に完了しましたが、次の「インストールの実行」でエラーとなりました。 # 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   .highlighter { background: linear-gradient(transparent 50%, #ffff52 90% 90%, transparent 90%); } .anchor{ display: block; margin-top:-20px; padding-top:40px; } .btn_A{ height:30px; } .btn_A a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_A a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; } .smaller { font-size: smaller; }

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サイト)   .btn_B{ height:25px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_B a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }  

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サイト)   .btn_B{ height:25px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_B a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }  

2020年10月26日

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

ERP、SFAツール、顧客管理システム、POSシステム・・・ 現在では、様々なシステムを活用してビジネスを展開することが当たり前となりました。それぞれのシステムを必要に応じて連携し利用することによって、組織全体としてシステムやデータをより有効に活用できます。 本コラムでは、システム連携の代表的な手法や課題などを解説します。 ▲ 欲しい製品・ソリューションが見つけやすくなりました! 目次 システム連携とは? システム連携の代表的な方法 幅広いシステム連携方法に対応するのはコストがかさみ、手間も増える・・・ 用途・目的に合ったシステム連携の方法を選べる統合プラットフォーム「IBM Cloud Pak for Integration」 お問い合わせ 関連情報 システム連携とは? かつて、システムは一部の大企業だけのものであり、大型メインフレームの導入が主流でした。しかし、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の利点は大容量データを高速でやり取りすることです。 データ連携は通信プロトコルである 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]でも紹介しています。 お問い合わせ この記事に関するお問い合せは以下のボタンよりお願いします。お問い合わせ 関連情報 IBM Cloud Pak for Integration(製品情報)- アプリケーション、データ、クラウド・サービス、APIの統合を支援するハイブリッド統合プラットフォームです。 今、デジタルサービスに求められる必須要件とは!?アプリケーションのコンテナ化で得られる5つのメリット(コラム)- 今注目されている「コンテナ化」。コンテナ化とは?そのメリットとは? 【やってみた】IBM Cloud Pak for Applications導入してみた:概要編(ブログ)- シリーズ第1回目の本記事では、概要編として検証の目的・背景や環境周りを紹介します。 全ての企業が AI カンパニーになる!「IBM THINK Digital 2020」に参加した(ブログ)- 全世界から9万人以上の参加者が!   ul#list li{ margin-top:10px; margin-bottom:10px; } ul#list a{ font-weight:bold; } .anchor{ display: block; margin-top:-20px; padding-top:40px; } .btn_B{ height:25px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_B a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .btn_CTA{ height:30px; margin-bottom:40px; width:450px; } .btn_CTA a{ display:block; width:100%; height:100%; text-decoration: none; background:#6200f5; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #6200f5; transition: all 0.5s ease; } .btn_CTA a:hover{ background:#bf94ff; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #bf94ff; } .bigger { font-size: larger; }

2020年09月30日

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

近年、大規模な自然災害が増加していることから DR の重要性が高まっています。 DR は「Disaster Recovery」の略であり、文字どおり「災害時にどう復旧するか」という対策を指します。 ひと言で「災害からの復旧」と言っても対策は多岐にわたり、求める対策のレベルによって運用にかかるコストにも違いがあります。 どこまで対策をすればいいのか、悩む企業も多いのではないでしょうか。 今、改めて押さえておきたい DR の基本・指標と、実現するための方法について解説します。   Index DRの基本と、BCPとの違い DRで最初に検討すべき3つの指標 DRを実現する3つの方法 バックアップ製品などをうまく活用し、効率的な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 対策を目指しましょう。     この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ   関連情報 今、BCPで求められるITシステム対策について解説。考えるべき基本は?最優先すべきポイントは? (コラム) - 災害など緊急事態における対策を定める「BCP」。では、具体的にどうすればよいのか?   .btn_B{ height:25px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_B a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }  

1 7 8 9 10 11 20
back to top