NetApp Tech OnTap NetApp Logo
NetApp Tech OnTap
     
コンバージドインフラとハイパーコンバージドインフラの適材適所とは?≪後編≫
~エンタープライズ IT の基盤選択のあり方を考える~
シェアするNetAppオフィシャルFacebook   ツイート

 

「コンバージドインフラとハイパーコンバージドインフラの適材適所とは?≪前編≫」はこちら

広範囲な分野で豊富な実績を持つ FlexPod

ここまで、 CIHCI の特徴および適性を論じてきたが、的確な選定のためには最新の製品動向を織り込む必要があります。≪前編≫の図 1 で示したように、同じ CI に分類される製品でも、その適性は製品ごとに異なります。そこでここからは、 FlexPodNetApp HCI について、より詳しく見ていきたいと思います。以下では、共有ストレージを採用する「 FlexPod Express/Datacenter/Select 」のことを「従来型 FlexPod 」と呼びます。なお、 FlexPodNetApp HCI の詳細な比較を図 2 にまとめました。以下の解説と併せてご参照いただきたいと思います。

前述した通りで、 FlexPod はシスコのサーバーやネットワーク機器と、ネットアップのストレージを組み合わせた CI 製品です。従来型 FlexPod は、超低レイテンシーが求めら れるデータベースや HPC、 高いデータ管理性が求められる仮想環境やビジネスアプリケーション、スケールアウト指向のあるアプリケーションまで、幅広いシステム基盤として多くの実績を積み上げてきています。

IT インフラの統合管理やセルフサービス化に優れる点も特徴であり、 UCS サーバーは UCS Manager で、 Nexus スイッチは SDN 基盤の ACI での統合管理に対応しています。ネットアップの OnCommand シリーズによる管理を UCS Director に統合することで、物理/仮想が混在した環境でも、構成自動化や利用者からのリソース要求への対応が可能です。

さらにアプリケーション管理ツールの CloudCenter により、ハイブリッドクラウドでの高い管理性も実現しています。具体的には、アプリケーションの「モデル化」「展開」「管理」のサイクルを CloudCenter がクラウドの違いを越えて一元管理します。クラウドの違いを意識する必要のないアプリケーションの展開・管理・利用が可能な環境を整備できるようになっています。

netapp cloud volumes for aws

2:従来型 FlexPodFlexPod SFNetApp HCI の機能および管理特性の比較

ネットアップとシスコ、さらにパートナー各社とのパートナーシップにより、一貫したサポート体制も整備されています。万一の問題発生時には、情報共有による適切なエスカレーションや、共同トレーニングで継続的に修得してきた知識による速やかな対応が実現されています。

CI は共有ストレージを使う関係から、高密度なサーバー統合や VDI (デスクトップ仮想化)などでは、ストレージへのアクセス集中による処理性能低下を招きやすいとされています。ただし、 FlexPod はこの指摘には該当しません。従来型 FlexPod でも、オールフラッシュ・ストレージの「 NetApp All Flash FAS(AFF) 」を採用することで、ボトルネックを大幅に緩和できるからだ。共有ストレージを採用する CI は拡張性に上限があるものの、従来型 FlexPod はその上限を大きく引き上げることで CI の適用分野を大きく拡大させています。

SDS で拡張性の壁を取り除いた FlexPod SF

従来型 FlexPod が備える特徴の多くを引き継ぎつつ、 SDS 型ストレージの「 SolidFire 」を採用した CI 製品が FlexPod SF です。 FlexPod SF は、サーバーもストレージもすべて Cisco UCS で構成され、 SolidFireElement OSCisco UCS 上に搭載することで、ストレージを完成させています。 SolidFire の採用により、柔軟性の高い拡張性が実現されているのが特徴だが、 SolidFire による恩恵はそれだけではありません。

SolidFire は、各アプリケーションに対してストレージボリュームレベルでパフォーマンスと容量(最大、最小、バースト時)を個別に設定できる QoS 機能を備えています。この QoS 機能を活用すれば、マルチテナント構成で課題となる“ノイジーネイバー問題”(同一ノード内で実行されるワークロードの負荷が互いに干渉して性能劣化を引き起こす問題)を排除し、サービスレベルを維持することが可能となります。

また、 SolidFire は独自の自己修復型アーキテクチャにより、ディスク障害からのリカバリも完全に自動化します。数分で復旧処理を完了させることが可能です。

さらに、この SolidFire は、インフラの運用自動化にも大きく貢献します。 SolidFire は、世の中で公開されている様々なソフトウェアやクラウドなどの API に対応しているため、 100% プログラマブルな自動化されたインフラを実現することができます。

従来の HCI の概念を覆す NetApp HCI

続いて、 NetApp HCI を見きたいと思います。 NetApp HCI は、サーバーとストレージの両ノードを完全に分離、「 HCI1 筐体にすべてのリソースを詰め込んだもの」という既成概念を覆す HCI 製品です。これにより、 NetApp HCI はサイジングの容易性を CI レベルにまで高めています。コンピューティングノードだけ、ストレージノードだけの追加が可能なため、 HCI の課題の節で触れた、余剰リソースの生みやすさという問題も解消されます。なお、ノードの追加は、完全に無停止で行うことが可能です。

ストレージは、 FlexPod SF と同じく SolidFire の技術をベースにしており、 QoS 機能や自動修復機能によるストレージ管理の高度化と自動化を実現しています。特に QoS 機能によるサービスレベル保証は、仮想化を前提とする HCI では重要となります。仮想マシンの配置が自動化されている HCI では、前述のノイジーネイバー問題がより発生しやすいからです。

NetApp HCI は、ハイパーバイザーには VMware vSphere ESX を採用しています。独自の管理機能も「 VMware vCenter Server 」に統合されており、仮想マシンのプロビジョニングや QoS の設定、ログ確認、レポーティングなども vCenterUI から実施できます。公開された API によって、各種クラウド管理環境との統合も可能です。

さまざまなシステムでの活用が見込める NetApp HCI だが、とりわけ仮想化技術によるシステムの標準化や自動化、ホスティング基盤の構築、 DevOps による開発の推進などの 目的に合致した製品と言えます。

システム要件と運用管理スタイルから見た使い分け

CIHCI の垣根は着実に低くなりつつあり、ここまで見てきたように従来型 FlexPodFlexPod SFNetApp HCI の特徴および適用分野はオーバーラップしている部分も多くなっています。そこで、製品選択の目安となる、システム要件と運用管理スタイルについて見ていきたいと思います。

システム要件による使い分け

システム/アプリケーションには、満たすべき要件が必ず設定されています。処理性能やダウンタイムなどが代表例だが、内容はシステムごとにさまざまです。そのさまざまな要件に柔軟に対応できることを優先するのであれば、 CI (従来型 FlexPod )が一番の候補となるでしょう。従来型 FlexPod は、多くの事前検証済みデザインガイドを用意し、作りこみに対応しやすく、技術的に枯れ、運用ノウハウの蓄積も豊富にあり、ミッションクリティカルなシステムの厳しい要求にも応えやすいからです。

一方の HCINetApp HCI )は、カスタマイズが必要なシステム/アプリケーションには不向きである。 HCI の特長は、「シンプルであるが故に管理と拡張が容易」という点にあり、特別な運用フローを必要とするシステムを HCI に持ち込むことは、 HCI の良さを損なうことになりかねません。 HCI の管理性や拡張性の高さが最大限に発揮されるのは、標準的な構成のシステムを大量に運用するような場合です。

これらを勘案すれば、大きなカスタマイズが生じやすい基幹システムなどの稼働基盤には従来型 FlexPod を、それら以外のシステムは NetApp HCI を基盤に採用すべきと結論付 けられます。

なお、 FlexPod SF は、従来型 FlexPod と同様に物理/仮想のどちらでも使え、混在も可能であるなど、システム要件に合わせた作り込みが可能です。ただし、新製品であるが故に現時点では実績が少ないこと、またストレージ管理では、 NetApp AFF などストレージ専用機を採用する従来型 FlexPod のほうがよりきめ細やかな管理が可能であることに留意する必要があります。

運用管理スタイルによる使い分け

上述したように、 NetApp HCI では VMware vCenter に管理機能が統合されているだけでなく、各種自動化機能で、管理工数の大幅な削減が実現されています。これは、 IT スタッ フが少ない企業にとって大きなメリットになります。また、 FlexPod SFSolidFire の自動化機能によりストレージ管理の軽減が図られており、専任のストレージ管理者がいない企業が構成自由度の高い IT 基盤を求める場合は有力な選択肢になるでしょう。自動化機能による管理負荷の削減は、開発者を中心とした DevOps 志向の強い企業にも適しています。開発者自身でインフラを管理できてしまう簡易性を備えているからです。

一方で、自動化機能の活用は、運用担当者が管理権限の一部を手放すことも意味しています。システムの中には、ある程度工数がかかってもきっちり細かく管理したいものもあり、そうしたシステムの管理者には、状況を把握してからオペレーションを実行したいと思う人も多いでしょう。例えば、ディスク障害発生時のリビルドを営業時間外で実行したいといったケースです。また、サーバー、ネットワーク、ストレージの管理分業体制が確立していて、それぞれにノウハウが蓄積されている企業では、むしろオーソドックスな構成の従来型 FlexPod のほうがスムーズに導入できることも多いはずです。運用フローや体制の見直しといった人がからむ変更は、モノの変更よりも大事になる可能性が高いです。

CI よりも HCI のほうが構築・運用が容易というのは、一般論としてはそのとおりなのですが、自社の運用管理体制と照らし合わせて吟味する必要があります。現在の体制でうまく回っているのであれば、体制変更を伴うIT基盤の変更は大きなリスクとなります。一方、管理負荷が増大し、現体制に限界を感じているのであれば、 FlexPod SFNetApp HCI のような製品を中心に IT 基盤を再編することが、有効な打開策となるでしょう。

Data Fabric で環境の違いを越えたデータ管理を実現

さて、ここまでハイブリッド型システム基盤の受け皿となるオンプレミス側の IT 基盤として、 CIHCI を論じてきましたが、最後にクラウド側の受け皿について解説しておきたいと思います。

オンプレミスと各種クラウドの使い分けや連携で課題となるのが、データの保護や可用性確保、バックアップ、災害対策などの手法の違いに起因する、データのサイロ化です。その解消に力を発揮するのが、異なるクラウド環境とオンプレミスをシームレスに相互接続し、同じ管理体系でのデータ活用の実現を目指す NetApp ストレージの管理ビジョン「 DataFabric 」です。

ストレージ OSNetApp ONTAP をクラウドで動作させる「 ONTAP Cloud 」や、 NetApp ストレージをクラウド事業者のコロケーション施設で利用し、 AWSAzure といったパブ リッククラウドのコンピューティングリソースと接続するソリューション「 NetApp Private Storage for Cloud 」は、 Data Fabric の代表的な構成要素です。

そして当然ながら、 FlexPodNetApp HCIData Fabric に対応しており、 Data Fabric を介して各種パブリッククラウドとのデータ相互活用が可能です。 FlexPodNetApp HCI をワークロード特性や自社の運用管理スタイルによって使い分けつつ、パブリッククラウドも含めたデータとアプリケーションの統合管理を実現します。これがハイブリッド型システム基盤の実現に向けた、有力な現実解であることに疑問の余地はありません。

2018 年 05 月

Go further, faster
お問い合わせ   |   購入方法   |   フィードバック   |   採用情報  |   登録   |   プライバシーポリシー   |   © 2018 NetApp