クライム・クラウド・カンパニー 感謝祭2016での AWS re:Invent 2016 報告！

投稿日: 2017年1月2日 クライム
クラウド・仮想インフラ

2016年11月28日～12月2日までの5日間にアメリカのラスベガスで開催された「AWS re:Invent」に弊社社員が参加しました！ 2016年12月8日に開催しましたクライム・クラウド・カンパニー 感謝祭2016での AWS re:Invent 2016 報告です。

クライム・クラウド・カンパニー 感謝祭2016について

タグ: ,

バックアップ・ストレージへのランサムウェア攻撃を防止するための7つの実践的なヒント　[ネットワーク強靭化対策]

投稿日: クライム
クラウド・仮想インフラ

ransomwareバックアップ・ストレージへのランサムウェア攻撃を防止するための7つの実践的なヒントを紹介します。

1.バックアップ・ストレージに対して別々の認証情報を使用する

これは最も一般的なベストプラクティスで、ランサムウェア(Ransomeware )に対して最も重要です。バックアップ・アクセスに使用されるユーザ名は厳格に保持され、この目的のみに使用されるべきです。さらに実際にバックアップ処理に必要なアカウント以外のバックアップストレージにアクセスできる他のセキュリティは使用すべきではありません。どんな場合でもすべてにDOMAIN\Administratorを使用すべきではありません。

2.可用性ストラテジーの一部としてオフライン・ストレージを持つ

バックアップ・ストレージへのランサムウェア暗号化の繁殖に対する最善な防御の1つはオフライン・ストレージを持つことです。Veeamのオフライン・ストレージには次のようなものがあります。

●テープ：ライト/リードで使用されていない時は完全なオフライン

●レプリケーションしたVM：パワーオフで、多くの状況では違った認証フレームワークの場合

●プライマリ・ストレージのストレージ・スナップショット：リカバリー・テクニックと使用でき、通常は別の認証フレームワークを保持

●クラウド・バックアップ：これはバックアップ・インフラに直接続ではなく、別の認証メカニズムを使用

●交換可能なメディア：ライト/リードで使用されていない時は完全なオフライン

3.バックアップ・ストレージに対して違ったファイルシステムの活用

異なるプロトコルが関わっていることは、トランザムウェアの繁殖を防ぐ別の方法になります。違った認証を使用してストレージにバックアップを置くこともアドバイスの1つです。最も良い例はドメイン・コントローラのようなクリティカルなものをバックアップすることです。万が一の場合、ドメインコントローラーを完全に復元する必要がある場合は、バックアップを含むストレージがActive Directoryで認証されたストレージリソースである場合に問題が発生する可能性があります。

よい例がLinuxシステムがレポジトリとして機能している場合です。このVeeamバックアップとリストア用認証はLinux認証で行うことができ、違ったファイルシステム(ext3, ext4 等)を使用することでランサムウェアの増殖リスクを軽減することができます。ランサムウェアは、他のオペレーティングシステム上にも存在しています。 しかしこの追加の手順は、オペレーティングシステム間のバックアップストレージの保護になります。

4.可能であればバックアップ・ストレージにストレージ・スナップショットを配置

ストレージ・スナップショットはプライマリ・ストレージ用の「セミ・オフライン」テクニークと呼ばれます。しかしバックアップを保持しているストレージ・デバイスがこの機能をサポートしている場合にはランスウェア攻撃を防ぐために活用する価値があります。

5.「3-2-1」ルールの使用開始

「3-2-1」ルールはユーザのメディア3つの別々コピー、2つの違ったメディアで、そのうちの1つはオフサイトにすることを意味します。これはほぼすべての障害シナリオに対処することができ、特定の技術を必要としません。ランサムウェアの分野にでは、メディアの1つがオフラインになるルールにもう1つを追加することを推奨します。オフライン要素を実装するためにインストールを完全に再構成する必要はありません。 しかし、これらのオプションを現状のデザインへの追加ステップとみなしてください。

6.怪しい動きに対する可視化

ランサムウェアの最も大きな脅威は他のシステムへの増殖です。可能性のあるランサムウェア活動を可視化することは重要です。Veeam ONE 9.5では「Possible ransomware activity」という新規プレ定義アラームが追加されました。このアラームはディスクへの大量の書込み、高CPU使用があった時をトリガーとします。

vone95

7．バックアップ・コピージョブの活用

バックアップ・コピー・ジョブは、通常のバックアップジョブとは異なる保存ルールで、異なるストレージに作成されたリストア・ポイントを持つ有用なメカニズムです。以前のポイントが組み込まれている場合、バックアップ・コピー・ジョブで使用されている復元ポイントが異なるため、バックアップコピージョブはランサムウェアの状況では貴重なメカニズムになります。

バックアップ・コピー・ジョブは、すでにリポジトリにあるバックアップを読み込んで、別のタイプの新しいストレージにリストア・ポイントを作成することができます。例えば、Linuxサーバのインフラストラクチャに特別のストレージ・デバイスを追加するオプションを1つ選択した場合は、そのLinuxサーバをVeeam Backup＆Replicationコンソールに追加し、そのファイルシステムにリポジトリを定義してから、 バックアップ・コピー・ジョブを作成します。

[参考ブログ] ランサムウェアの検知もVeeamで対応!! VeeamONE新アラート「Possible ransomware activity」

タグ: , ,

AWS Re:invent 2016 Breakout Session情報：木曜日

投稿日: 2016年12月2日 クライム
クラウド・仮想インフラ

AWS Re:Inventも最終日でRe:Playパーティなどもありましたが、ブログの方では引き続きセッションの情報を展開していきます。

DAT308： Fireside chat with Groupon, Intuit, and LifeLock on solving Big Data database challenges with Redis

オープンソースのNoSQLなインメモリデータベースプラットフォームRedisの事例紹介セッションでした。以下のユーザが実際にRedisの使い勝手や気に入ってる点などを紹介してました。

Intuit：高パフォーマンスなところ、ハードウェア要件が低く安定したパフォーマンス

LifeLock：セッション管理で使用し、Keystore機能が決めて

Groupon：ユーザデータを抽出してデータ集計を行うために使用、重複アカウントの検出が容易に

ENT202：Driving AWS Cost Efficiency at Your Company

AWS上でのコスト削減効果を解説するセッションでした。EC2ではなくECSやLambda、RedShiftなどのPaaSを使用する、EC2を使用する場合にもリザーブドインスタンスを用いるといった節約をすることで、使用量が増えてもてコスト削減を行い、使用率を最適化するというサイクルを繰り返し、単価を下げトータルコストを維持していく方法の解説を行っていました。

・ENT317：VMware and AWS Together – VMware Cloud on AWS

VMware on AWSの紹介セッションです。10月13日に発表されたVMware Cloud on AWSのデモを交えた紹介が行われました。VMware環境を簡単にAWS上にデプロイすることができるVMware Cloud on AWSのコンソールやAWSの各種PaaSにアクセス可能な点が強調されていました。また、VMwareがサービスとして提供するものであるため、VMwareとAWSの アカウントの構造なども紹介されていました。

DAT302：Best Practices for Migrating from Commercial Database Engines to Amazon Aurora or PostgreSQL

データベースをAmazon Auroraやオープン系のPostgresなどに移行するメリットや移行の際に使えるサービスを紹介するセッションでした。メリットとして大きく上げられて点はよく言われることですが、AWSの機能で自動的にバックアップや保護が行われる点です。また移行用のツールとしてはAWS Schema Conversion ToolとAWS Database Migration Serviceを使った移行です。弊社で取り扱っているDBMotoとは異なり、大きく2つのステップに分かれることになりますがSCTでテーブルの構成などをターゲットとするDBに合わせて変換後、DMSで実際のデータ移行を行います。

SVR305 ：↑↑↓↓←→←→ BA Lambda Start

AWS Lambdaのベストプラクティスセッションでした。Lambdaの概要から使い方、仕様や制限、さらにはHearst Corpが実際にcron-baseのデータパイプラインからLambdaを使ったどのようにトリガーベースに変更したのかを詳細に紹介していました。また、このようなサーバレスでの開発のために使用できるツールやフレームワークの紹介などもあり、なかなか濃いセッションとなっていました。

タグ: ,

AWS Re:invent 2016 Breakout Session情報：水曜日

投稿日: 2016年12月1日 クライム
クラウド・仮想インフラ

本日もラスベガスで行われているAWS Re:Invent 2016の情報を展開させていただきます。

・MBL306：Serverless Authentication and Authorization: Identity Management for Serverless Architectures

AWSでサーバレスアーキテクチャを実現する際の認証に焦点を当てたセッションでした。AWS Cognitoの認証を使用し、SRP（セキュアリモートパスワード）プロトコルとJWT（JSON WEB トークン）を使用した安全な認証を行い、S3などのAWS上のリソースにアクセスし、サーバーレスで簡単にアイデンティティ管理が行えるというものです。このセッションでは実際にどのように認証されるのか、IAMとの連携やSMALとの統合などを紹介するたびに、サンプルのアプリからのアクセスを行った場合のデモを交えて紹介していました。

このアプリはオープンソースで入手して実際に試せるようなので、興味のあるかたは是非お試しください。

https://github.com/awslabs/aws-serverless-auth-reference-app

・ARC318：Busting the Myth of Vendor Lock-In: How D2L Embraced the Lock and Opened the Cage

従来の方法でそのまま移行するのではなく、AWSのサービスに置き換えて移行することで、どんなメリットがあり、どれだけ節約できるのかを紹介していくセッションでした。例えばファイル共有であればDFSRからS3に、DNSであればRoute 53に、キャッシングであればKinesis FirehoseとElasticsearchというようにAWSが最適化したサービスを利用することでどれだけコストに差が出るのかといった点を強調していました。IaaS（EC2インスタンス）で、従来の手法のまま移行するのは確かに簡単かもしれませんがPaaSに置き換えることでコストの最適化し、AWSの最新機能も使用できるようになるというものです。

紫：EFS、黄：DFSR、青：NetApp Ontap（マーケットプレイス）、緑：S3

・ENT210：AWS Data Transfer Service

AWSへの各種データ移行方法の紹介セッションでした。VPNやインターネット経由でS3にアップロードする方法、Transfer Accelerationオプションの効果や仕組み、Direct ConnectやStorage Gateway、Snowboll、サードパーティのストレージなどを用いる方法などを紹介していました。

・ARC211： Solve common problems with ready to use solutions in 5 minutes or less

一般的な問題ならAWSが提供するソリューションで5分以内に解決できますよという内容のセッションでした。EBSのスナップショットやEC2のスケジューラ、VPNのモニターやGlobal Transit VPC、EC2のサイジング、アカウント管理など、一部は詳しい仕組みも含めての紹介でした。

タグ: ,

AWS Re:invent 2016 Breakout Session情報：火曜日

投稿日: 2016年11月30日 クライム
クラウド・仮想インフラ

基調講演は多くの方が展開していると思いますので、本ブログではRe:invent 2016で受講した各Breakoutセッションを紹介していきます。Re:inventでは500以上のセッションがあるので、ここで紹介させていただけるのは、ほんの一部ですが雰囲気だけでも感じていただければ幸いです。

・ENT212：Preparing for a Large-Scale Migration to AWS

どのように、AWSへの移行を促すか、また移行の際にはどのような準備が必要になるのかといった情報を解説するセッションでした。どのような場合、誰が、いつ移行を検討するのかという導入から、実際に移行を実現したFinancial Timesの事例を担当者自らが語りました。

Financial Timesではポンドの暴落が発生した際のアクセス数の急増を機会にAWSへの移行を検討し始めました。この移行のための準備でFinancial Timesがとった戦略はコンサルタントと社内トレーニングをハイブリッドに行い社内のスキルアップを行うというものです。コンサルタントに依頼する方法ではコストが、社内教育を行う方法では時間が多く必要になりますが、その両方を採用し、社内でのスキルアップを図り、イノベーションを実現しながら移行を実現しました。

また、移行時に発生するコストのバブルをどう改善するのかといったグラフも象徴的でした。移行により発生するバブルをコントロールし、移行後にはコストを監視し最適化を行っていくことで、移行によるコスト削減の効果を最大にした移行が可能になります。

・ENT204:Large-Scale AWS Migration

先のセッションと同じようなタイトルですが、移行サービスを提供するCSCがスポンサーとして講演し、実際に移行を行う際のプラクティスを解説するセッションでした。どのように準備を進めるか、小中規模環境と大規模環境での移行で考慮する点やチームの規模などの違い、目的とする移行（ライブマイグレーションなのか、コールドマイグレーションなのか、データの移行のみでいいのかなど）に合わせた移行方法の提供などの紹介でした。自身ののみで難しい場合には各パートナーと連携し最適な移行方法を提供しているとのことです。

・SAC308：Hackproof Your Cloud

AWSセキュリティ監視、管理ツールを提供するCloudCheckrがスポンサーとして講演するAWSのセキュリティで考慮する点を解説するセッションでした。AWS上でのECインスタンスへの接続方法の複雑さ（多様さ）やEC2インスタンスだけでなく、AWSには80を超えるサービスがあるためそれらにも注意が必要であり、その中の一つでもセキュリティホールとなれば全体の脆弱性につながる点を紹介していました。例えば基本的なことですがRDSのパブリックアクセスを行う場合にはソースIPの制限や最新パッチの適用をしっかりと行う必要がある点や、S3へのアクセス権限をちゃんと制限しましょうといった内容です。

余談ですがこのセッションは下のようなオペラハウスのような会場で実施されていました。

・WIN301：Bring Microsoft Applications to AWS to Save Money and Stay License Compliant using PowerShell, Windows KMS, and Dedicated Hosts

Windows ServerやSQL Server、SharePointのライセンスをどのようにAWS上のEC2に適用するのが良いのかという解説でした。AWS Importで取り込んだ専有ホスト、専有インスタンス、デフォルトテナンシーどれに既存のライセンスが適用し活用できるのかといった点から、ライセンスの形態の違い紹介し、最後には実際にPowerShellからインポートを行うデモを行っていました。

タグ: ,

ここで躓いた、AWSで構築の際のポイント ～ロードバランシング～

投稿日: 2016年8月15日 クライム
クラウド・仮想インフラ

前回はAWSからローカル間の通信で躓いたポイントを紹介しました。
今回は環境構築後に躓いたポイントと解決策をご紹介します。

以下がイメージ図となります。

work_1
簡単なシステムの流れは、外からのアクセスをELBで別々のEC2インスタンスに分散させ、
各EC2インスタンスから単一のRDSへデータの書き込みや読み込みを行います。
ページにアクセスした際、別のEC2インスタンスに自動的に切り替えて負荷分散するようなイメージです。
各EC2でOSを立ち上げ、VPCのセキュリティグループも何とか設定、RDSとも無事接続し
今回の肝であるELBを各EC2インスタンスに接続して、Health Checkも完了
あとはアクセスして動作確認をするだけ！

しかしいざページにアクセスし、更新をかけてページが切り替わることを確認しようとすると…
切り替わらない図1

EC2_1のページしか表示されませんでした。

慌ててELBの設定を確認するも…
状態は正常に接続されている「InService」と表示されるのみ…
設定を見直しても原因は見つからない
もしかしたらブラウザのキャッシュが原因で正常に動かないのかもしれない

ブラウザのキャッシュを削除し、再アクセス
F5キーで更新

図2

一度だけ切り替わりました。

しかしすぐにキャッシュが保持されてしまい、切り替えが出来なくなりました。

そこでキャッシュが残らない更新の仕方を調べてみると…
ありました！「スーパーリロードの方法」
早速スーパーリロード(ctrl + F5)で切り替えてみると…
継続的に切り替え成功

早速アカウント登録by EC2_1 で情報を入力し、切り替えてみると、

図3

無事切り替わりを確認することができました！

本来ロードバランサーは負荷がかかった際に、アクセスを切り替える機能で、負荷がかかっていない状態では切り替わらないのですが、「スーパーリロード」を行うことで、稼働しているか確認できました。

初歩的な部分ではありますが、ロードバランシング機能が正常に稼働しているか確認する際お使いいただければと思います。

 

タグ: ,

ここで躓いた、AWSで構築の際のポイント ～AWSからローカル間との通信～

投稿日: 2016年7月28日 クライム
クラウド・仮想インフラ

クラウドコンピューティングにおいて高い知名度を誇るAWS、我々クライム新入社員もAWSを使ってWEBサービスを試しに作りました。その際に、思わぬところで躓いたポイントと解決策をご紹介します。

WEBアプリケーションの展開について：

本記事で紹介する構成図は以下の通りです。

構成図

EC2とはAWSで仮想マシンのような役割のサービスです。またRDSはDBサーバをの役割を果たすサービスです。

EC2にHTTPサーバを導入し、そのHTTPサーバとRDSが通信を行います。

構築も非常に簡単で、EC2のインスタンスを立ち上げ、HTTPサーバを導入します。その後、RDSのインスタンスを立ち上げ、HTTPサーバと通信を行う設定をするだけです。
※インスタンスとは仮想マシンのコピーのようなものです。
　詳しくはインスタンスとAIMをご参照ください。

OSのセットアップやDBサーバの導入を行うことを行わず、簡単にWEBアプリケーションを展開できます。

躓いたポイント：

EC2のインスタンスを立ち上げた後、WAN経由などでインスタンスと通信を行う際に、セキュリティグループの設定や、パブリックIPが正しいのに接続ができないことがありました。

その場合、VPCのルートテーブルの設定に、EC2インスタンスが存在するサブネットが登録されていない可能性があります。ルートテーブルの設定が正しくないと、VPC上のサブネットでのルーティングが行えず、通信ができません。

設定方法について：

コンソール画面

  1. コンソール画面より[VPC]を選択。
  2. 左側の[ルートテーブル]を選択。
  3. 対象のルートテーブルを選択。
    ※IGW（インターネットゲートウェイ）とVPCのルートが記されているルートテーブルを
    参照してください。上の画像に記されているルートタブで確認できます。
    今回はカスタムルートテーブルに追加しました。
  4. 下側のサブネットの関連を選択し関連つけを行う。
    ※サブネットの関連付けは、AWSのルートテーブルのページを参照してください。

まとめ：

初歩的なことですが、EC2やRDSへ接続が上手くいかない場合は、ルートテーブルの設定を見直してみると解決の糸口になるかもしれません。

同じような症状の方がいらっしゃいましたら、ぜひ、この方法を試してみてください！

次回はロードバランサーの注意点をご紹介します

タグ:

vSphere 6では、スナップショット統合問題はもう過去のこと！

投稿日: 2016年2月24日 クライム
VMware vSphere

VMware vSphereのスナップショット統合処理は、常に問題を抱えています。特に大規模でアクティブな仮想マシンで問題となりやすいです。しかし、vSphere 6では、過去の問題を解決するためのいくつかの変更を導入しています。

新しい統合方法

vSphere 6.0以前では、VMスナップショットの統合とコミットは、同じ手順で行われます。ベース仮想ディスクとスナップショットディスクを“凍結”させるために追加のヘルパースナップショットが作成され、スナップショットディスクの変更をベースディスクに結合すると、ヘルパースナップショットもコミットされ、いくつかのポイントでI/Oがスナップショットではなく、オリジナルのディスクに発生します。

この処理は、シンプルに見えますが、詳細を見ると、運用環境に問題を引き起こしかねない動作をしています。仮想マシンに標準的なI/O書き込みがあった場合、ヘルパースナップショットのサイズも成長していきます。そして、ベースディスクに変更されたデータをコミットするため、追加のヘルパースナップショットを作成するかもしれません。

以前はオリジナルチェーンを統合している間、ヘルパースナップショットに新しいI/Oをリダイレクトしていました。オリジナルチェーンが統合されると、ヘルパースナップショットが統合されるまでどの程度の時間がかかるかを計算しました。このヘルパースナップショットは統合操作中にかなり成長していることが考えられます。ヘルパーを統合する時間が一定時間内(12秒)であれば、VMを停止し、ヘルパースナップショットをベースディスクに統合しました。許容可能な時間を超えた場合は、ヘルパーを許容時間内にベースディスクにコミットできるまで処理(オリジナルのヘルパースナップショットを統合している間、新しいヘルパースナップショットに書き込み)を繰り返します。

定義された回数、処理を繰り返しますが、I/Oの量によっては、スナップショットチェーンとヘルパーの統合が成功しない場合がありました。

vSphere 6.0では、この統合処理が劇的に変更されました。

スナップショット統合処理もStorage vMotionのようにミラードライバを使用します。ミラードライバのメカニズムでは、統合中のVMへの変更がアクティブなVMDKとベースディスクに書き込み順序を保護しながら書き込まれます。そのため、うまくいけば、ヘルパーディスクを使うことなく1度でスナップショットの統合が完了し、停止時間を劇的に短くし、統合失敗の可能性が少なくなります。

新しい統合処理のテスト

これが本当であれば、とてもうれしいことなので、Veeamのエンジニアがテストしました。

テストは、ESXi 5.5 Update 3とESXi 6.0 Update 1bの2つのサーバで行いました。それ以外は同じ環境です。VMは12個の仮想ディスクを持っています。スナップショット統合の問題は、VMにたくさんのVMDKを持っている顧客でよく見られるためです。完全に空のVMでさえ、ディスクごとにたいてい約1秒の停止が発生するので、11ディスクもあると10秒以上の停止が発生してしまいます。

思い出してほしいのが、これがI/Oが全くない状態であるということです。例えば、データベースマシンのようなアクティブなVMでは、さらに悪化するでしょう。

各テストでは、2つのパラメータが測定されています。秒単位で実行されたネットワークpingとVMwareログから読み取った実際の停止時間です。1つ目はVMに接続されているネットワークを介して他のアプリケーションやユーザから見ることができます。2つ目は、スナップショットの作成と統合を管理するVMwareエンジンが費やす正確な時間です。

ESXi 5.5 U3

スナップショットの作成と削除の影響を確認するため、異なるテストが行われます。初めに、スナップショットを取得します。スナップショットの作成でさえ、ベースディスクからスナップショットのディスクへのI/Oリダイレクトが必要となり、この時間は最小限であっても0ではありません。

2016-02-05T22:52:22.064Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 1960925 us
Reply from 192.168.60.159: bytes=32 time=1ms TTL=62
Reply from 192.168.60.159: bytes=32 time=2ms TTL=62
Reply from 192.168.60.159: bytes=32 time=1ms TTL=62
Request timed out.
Request timed out.
Reply from 192.168.60.159: bytes=32 time=3ms TTL=62
Reply from 192.168.60.159: bytes=32 time=22ms TTL=62
Reply from 192.168.60.159: bytes=32 time=2ms TTL=62
Reply from 192.168.60.159: bytes=32 time=2ms TTL=62

スナップショットの作成には1.96秒かかり、ほぼ2秒です。実際に2 pingをロストしています(1秒ごとにpingを実行しているため)。

スナップショットの作成後、それを削除します。

2016-02-05T22:57:02.783Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 843578 us
2016-02-05T22:57:04.633Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 1224454 us
2016-02-05T22:57:06.457Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 1180217 us
2016-02-05T22:57:08.193Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 1125963 us
2016-02-05T22:57:09.870Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 1083360 us
2016-02-05T22:57:11.517Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 1061894 us
2016-02-05T22:57:13.124Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 1014733 us
2016-02-05T22:57:14.623Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 967550 us
2016-02-05T22:57:16.131Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 1004541 us
2016-02-05T22:57:17.600Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 961571 us
2016-02-05T22:57:18.980Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 907337 us
2016-02-05T22:57:20.338Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 890165 us
2016-02-05T22:57:21.162Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 383551 us

複数の停止操作があり、それらは合計で12648914マイクロ秒、つまり12.6秒です。前述したように仮想ディスクごとに約1秒の停止があります。この結果、複数のpingが失われています。

Reply from 192.168.60.159: bytes=32 time=1ms TTL=62
Reply from 192.168.60.159: bytes=32 time=2ms TTL=62
Request timed out.
Reply from 192.168.60.159: bytes=32 time=1ms TTL=62
Reply from 192.168.60.159: bytes=32 time=1ms TTL=62
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 192.168.60.159: bytes=32 time=1ms TTL=62
Reply from 192.168.60.159: bytes=32 time=2ms TTL=62
Reply from 192.168.60.159: bytes=32 time=2ms TTL=62

これがよく知られている仮想マシンが応答しなくなる状況です。

ESXi 6.0 U1b

次に、vSphere 6で同じテストを行います。初めに、スナップショットを取得します。

2016-02-05T22:06:11.606Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 649684 us
Reply from 192.168.60.159: bytes=32 time=1ms TTL=62
Reply from 192.168.60.159: bytes=32 time=1ms TTL=62
Reply from 192.168.60.159: bytes=32 time=1ms TTL=62
Reply from 192.168.60.159: bytes=32 time=2ms TTL=62
Reply from 192.168.60.159: bytes=32 time=2ms TTL=62
Reply from 192.168.60.159: bytes=32 time=1ms TTL=62

停止は0.6秒続き、pingは失われませんでした。

次に、スナップショットを削除します。

2016-02-05T22:10:08.276Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 5326 us
2016-02-05T22:10:08.493Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 69898 us
2016-02-05T22:10:08.714Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 63095 us
2016-02-05T22:10:08.942Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 67560 us
2016-02-05T22:10:09.166Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 65347 us
2016-02-05T22:10:09.388Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 64597 us
2016-02-05T22:10:09.610Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 63449 us
2016-02-05T22:10:09.827Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 65439 us
2016-02-05T22:10:10.054Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 69483 us
2016-02-05T22:10:10.277Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 65957 us
2016-02-05T22:10:10.501Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 64563 us
2016-02-05T22:10:10.759Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 95898 us
2016-02-05T22:10:10.983Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 67014 us

ディスクごとの単一の停止時間は約1秒から65 msに劇的に削減されています。これは、平均15倍の改善です！全体の停止時間は、1秒未満の828436マイクロ秒です。この結果、ネットワーク経由でのこのVMの可用性に飛躍的に向上しています。

Reply from 192.168.60.159: bytes=32 time=2ms TTL=62
Reply from 192.168.60.159: bytes=32 time=2ms TTL=62
Reply from 192.168.60.159: bytes=32 time=1ms TTL=62
Request timed out.
Reply from 192.168.60.159: bytes=32 time=1ms TTL=62
Reply from 192.168.60.159: bytes=32 time=3ms TTL=62
Reply from 192.168.60.159: bytes=32 time=1ms TTL=62

停止のタイミングと一致して1 pingのみ失われました。

 

参考: With vSphere 6, snapshot consolidation issues are a thing of the past!

 

タグ:

AWSアカウントでCloudWatch Billing Alarms と Threshold Notificationの設定

投稿日: 2016年2月21日 クライム
クラウド・仮想インフラ

ステップ1：ユーザアカウントで「Billing Alert」の設定

●AWS Management Consoleにサインインし、Billing and Cost Management Сonsoleをオープン
●ナビゲーションからPreferencesを選択
●Receive Billing Alertsチェックボックスにチェックを入れます
enable-billing-alerts-aws-console

●Save Preferencesを選択

これでAWSアカウントでの「Billing Alerts」が可能になりました。次に「Email」とSMS通知の設定を行います。

ステップ2：「SNS Topic」と「Appropriate CloudWatch Alarm」の設定

このステップは3つの連続処理に分かれます。最初にAmazon SNS notificationリストを作成する必要があります。

●Amazon SNSコンソールをオープン
●ナビゲーションからSNS Homeを選択
●Common actionsでCreate topicを選択
Create-SNS-topic-to-configure-billing-alerts-warrow

●ダイアログ・ボックスでTopic nameに通知用の名前を入力します。
●オプション：この通知にSMSメッセージを使用したい時はDisplay名にSMSメッセージに使用したい名前を入力
●Create topicを選択
●ナビゲーションで、Topicsを選択し、作成したTopicsを選択
●Create Subscriptionを選択し、EmailかSMSを選択し、アドレス、または電話番号を指定
sns-topic-create-subscription

●続いてのAWSからの確認レターでのリンクでEmailアドレスを確認

注：このEmailアドレスに確認をしない時は、転送はそれが終了するまで確認はペンディングとして取り扱われ、メッセージは送られません。

次に CloudWatchアラームの設定：

●CloudWatch Consoleをオープン
●必要があればナビゲーションでリージョンを変更
●ナビゲーションで、Metricsの下のBillingを選択
●Create Alarmを選択

create-billing-alarm-amazon-cloudwatch

●新規ウィンドウでShow advancedを選択し、すべての指標が正しいかを確認
create-billing-alarm-cloudwatch-details

Billing指標（メトリクス）で、メトリクス・チェック・ボックス（currencyの次）がEstimatedChargesを含んでいることを確認してください。
metric-estimatedcharges-create-alarm-threshold

●Nameの設定、オプションとして新規アラームの記述

次にアラーを次のように定義：
●「when my total AWS charges for the month exceed」チェックボックスで、希望する合計を設定
注：2つのアラームを設定することを推奨します。予算の半分に届いた時と予算を越えた時

●ドロップダウンメニューからAmazon SNS notificationを選択し、ボックスのメール・アドレスを入力し新規リストを作成します。
send-notification-configuration-connect-to-sns
Create Alarmの選択

ユーザのアラム状況を確認するにはナビゲーションからAlarmsへ移動します。

結論：
ユーザはこれでAWSアカウントように請求通知が可能になりました。規定した予算を越えた時にいつでもユーザのEメール、携帯電話に通知が送られます。

タグ: , ,

ESXi仮想マシンのスナップショットのチェーンはどのように維持されている？

投稿日: 2015年12月21日 クライム
VMware vSphere

VMware ESXiのスナップショット機能は仮想マシンの機能では最もポピュラーな機能です。
重大な変更の前に予めスナップショットを取得しておけば、いざ変更により問題が生じたとき、そのスナップショットの段階まで仮想マシンの状態を巻き戻すことが可能です。
複数のスナップショットを保持することが可能なので段階を分けてスナップショットを取得することもできます。

複数のスナップショットを保持している場合、たいていは階層化されて保存されています。
この階層チェーンを保持するのに使われているのはコンテントID（以下、CID）というものです。
このCIDはそれぞれのvmdkファイルに一意に割り当てられるハッシュ値です。

ベースとなる親vmdkファイルのCIDと、スナップショットとなる子vmdkファイルのCIDは別になります。
この親と子を結びつけるために使われるのはparentCIDという項目で、子のvmdkファイルのparentCID値は親ファイルのCID値と同一になります。

つまり、通常は以下のようになります。

cid_relation

このparentCIDとCIDを使うことにより、延々とスナップショットを作成し続けても、つながりが維持されます。
しかし、もしスナップショット操作で問題が生じたとき、parentCIDが親のCIDと異なる値になることがあります。これはCID mismatch errorという事象で、仮想マシンが起動できなくなる恐ろしいエラーです。

ここからが本題です。
上の場合は、起動状態の仮想マシンに対し、スナップショットを取得した場合の話です。
停止状態の仮想マシンに対し、スナップショットを取得したときはまた別の動作をします。

スナップショットのvmdkファイルを開いてCIDとparentCIDを確認しましょう。
驚くべきことに、CIDとparentCIDが同一です！自分自身を参照しているようです。
自分自身を参照していては、CID mismatch errorが起きてしまうのではないでしょうか？

ubuntu_snapshot_no_write2

ご安心ください。ここで親のvmdkファイルを開きます。
そうすると、親のCID値が子のparentCID値と一致します。
ちゃんとチェーンが保たれていますので、CID mismatch errorは起きません。

ubuntu_parent_vmdk_2

では、なぜスナップショットのCID値とparentCID値は同一なのでしょうか。

ドキュメント上明記されているわけではないので推測となりますが、VMwareの仕様として、
スナップショット自身の管理情報が書き込まれているのみで差分データがない、
つまり仮想マシンの実データが書き込まれていないスナップショットvmdkファイルのCID値は、親のvmdkファイルのCID値と同一になるようです。

もしここで仮想マシンを起動すれば差分データが発生しますが、その瞬間にスナップショットvmdkファイルのCID値は一意のものに変更されます。

ubuntu_snapshot_written2

仮想マシンを止めて変更を撤回（Revert）すれば割り振られたCID値も戻ります。

タグ: , , , , ,

ESXi 6.0.xでCBT(変更ブロック追跡)を有効にした仮想マシンをバックアップすると誤った変更セクタが返されます。

投稿日: 2015年11月30日 クライム
VMware vSphere トラブル

VMwareより重大な不具合に関する情報が公表されました。それは、ESXi 6.0.x上の仮想マシンをCBTが有効な状態でバックアップすると、増分バックアップ時に誤った変更セクタが返されてしまうというものです。

フルバックアップ時には問題ありませんが、この時に作成したスナップショットを統合する際に、CBT情報が失われます。そのため、CBTデータを用いた増分バックアップを行う際に、失われたブロックが含まれず、バックアップに一貫性がなくなってしまいます。その結果、正常に仮想マシンを復旧できない可能性があります。
これは、CBTデータを用いるすべてのバックアップソリューションに影響のある問題です。

現在、この問題に対するパッチがリリースされています。早急に適用することを推奨します。

参考: Backing up a Changed Block Tracking enabled virtual machine in ESXi 6.0.x returns incorrect changed sectors

タグ: ,

EMC vVNXでVVOLを用意してみる【その３：VVOLを設定してみる】

投稿日: 2015年10月23日 クライム
VMware vSphere

VMware vSphere v6.0でついに登場したVirtual Volume(VVOL)を検証できる、SANストレージを作成できる仮想アプライアンスEMC vVNX Community Edition 3.1.4の設定方法を案内する記事シリーズ3回目です。
前回の記事では、VVOLに必要なvVNX上でのストレージ設定である、ストレージプールの作成、NASサーバの作成、ESXiホストの認識設定、そしてProtocol Endpointsの設定の方法を案内しました。
今回の記事では、ついにVVOL接続に必要な設定を案内します。

44

ストレージプールをVVOLとして登録します。「Storage -> VMware -> Datastores」と進み、「＋」をクリックしてウィザードを開きます。

45

ウィザードでは作成するVMwareデータストアのタイプを訊かれます。一番下のVVOL(File)を選択します。

46

データストア名を決めます。ここで設定した名前が表示されるので、わかりやすい名前を入力します。

47

データストアに割り当てるCapacity Profiles、つまりストレージを決定します。ここではPerformance Tierを選択します。

48

サマリが表示されるので、これで問題なければFinishを押して作成します。

50

作成されたVVOLデータストアはこのような一覧表示になります。このデータストアをvCenterおよびESXiに認識させます。

51-2

vCenter Web Clientを開きます。「ストレージ」から「vCenter」を選択し、「管理」タブから「ストレージプロバイダ」を選択します。
緑の「＋」ボタンを選択すると入力ウィザードが開くので、プロバイダを登録します。
名前は任意のものでかまいません。URLは「https://（管理コンソールIPアドレス）:8443/vasa/version.xml」、認証情報は管理コンソールアクセス用のものを使用します。

53

OKを押すと登録されます。登録された段階ではまだVVOLデータストアが認識されていないので、ストレージプロバイダを再スキャンして認識させます。

54

データストア登録画面に移ります。ウィザードを開くとデータストアタイプを訊かれるので、「VVOL」を選択します。

55

バッキングストレージコンテナ一覧に、設定したVVOLが表示されるのでこれを選択します。

56

接続するESXiホストを選択します。ESXi 6.0のホストのみがVVOLに接続できます。ここでは6.0である244以外は選択できないようになっています。

57

最後に概要が表示されるので、これで問題なければ終了で設定を完了します。

58

これでEMC vVNX上で設定したVVOLストレージがESXi 6.0ホストに接続できました！
VVOLデータストア上には当然仮想マシンを設置できますので、製品の検証を行うこともできますし、VVOLの威力を確かめることも可能です。
この記事シリーズはここで終了です。この紹介が皆様のお役に立てれば幸いです。

タグ: , ,

EMC vVNXでVVOLを用意してみる【その２：ストレージを設定してみる】

投稿日: 2015年10月22日 クライム
VMware vSphere

VMware vSphere v6.0でついに登場したVirtual Volume(VVOL)を検証できる、SANストレージを作成できる仮想アプライアンスEMC vVNX Community Edition 3.1.4の設定方法を案内する記事シリーズ2回目です。
前回の記事では、ovaテンプレートから展開し管理コンソールを利用するまでの、EMC vVNXのインストールの一連の流れを説明しました。
今回の記事では、VVOLに必要なvVNX上でのストレージ設定である、ストレージプールの作成、NASサーバの作成、ESXiホストの認識設定、そしてProtocol Endpointsの設定の方法を案内します。

11

まずはvVNXにVVOL用の仮想ハードディスクを接続します。ここでは試しに2つ接続します。

12

すると、EMC Unisphere上の「System -> System View -> Virtual」に、追加されたストレージが表示されます。
このストレージから、まずはストレージプールを作成します。

13

「Storage -> Pools」とアクセスすると、ストレージプールの画面が出てきます。
画面上方にある「＋」をクリックします。

14

するとストレージプール作成のウィザードが開きます。ストレージプールの名前をName欄に入力します。

16

次に、割り当てるディスクとそのTierを設定します。
Tierはストレージのパフォーマンスレベルを決定するもので、パフォーマンスを最大化する「High Performance Tier」、パフォーマンスを比較的重視する「Performance Tier」、パフォーマンスよりもキャパシティを重視する「Capacity Tier」があります。
Tierが割り当てられていないストレージは、どのストレージプールに割り当てられません。例としてここではPerformance Tierを選択します。

17

１つのストレージプールには単一のTierのみが選択可能です。Performance Tierを選択します。

18

Performance Tierグループのディスクのうち、割り当てるディスクを選択します。１つしかないので、これを選択します。

19

VMwareのCapacity Profileをストレージプールに作成します。VVolで使用するストレージプールはこのCapacity Profileを設定する必要があります。
プロファイル名を入力します。

20

Tierを仮想マシンに割り当てるvSphereポリシーを作成しやすくするためにタグを割り当てます。例としてここではProductionと入力します。

22

最後にサマリ画面となるので問題なければFinishを押します。左の画面になれば作成完了です。
これをもう１つのディスクに繰り返して実施することも可能です。

23

ストレージプールの一覧表示は左のようになります。

24

VVOLを設定するにはNASサーバが必要ですが、これはEMC vVNXの設定内で、ストレージプールを使って構築します。
「Storage -> File -> NAS Servers」の画面から、画面上方の「＋」をクリックして設定ウィザードを開きます。

25

ウィザードで、NASサーバ名と、割り当てるストレージプール、ストレージのプロセッサを選択します。プロセッサはデフォルトで入力されていますので、サーバ名とストレージプールを選択するだけでかまいません。

26

次にこのNASサーバがもつネットワークポートの設定をします。
口となる仮想NICを選択し、NASサーバがもつネットワーク設定を入力します。選択した仮想NICに割り当てたネットワーク設定を使用してはいけません。

27

次に共有プロトコルを選択します。
VVOLで使用する場合、Linux/Unix shares(NFS)を選択し、Enable NFSv4は選択しません。
次の２つの画面はUnix Directory ServiceとDNSの設定ですが、これはチェックを入れずにスキップして問題ありません。
サマリが表示されるのでFinishをクリックして設定を完了させます。

31

NASが完成すると左の画面のようになります。

32

次にEMC vVNX側からVMwareのホストを認識させます。例として、ここではvCenterを登録して認識させます。
「Access -> VMware -> vCenters」を選択し、「＋」をクリックしてウィザードを開きます。

33

ウィザードが開きます。vCenterと認証情報を入力し、登録するESXiホストを選択します。6.0だけでなく、5.xのホストも選択可能です。
Nextを押すとサマリ画面が開くので、Finishをクリックして登録を完了します。

37-3

vCenterおよびESXiホストは左の画面のように表示されます。

38

続いて、Protocol Endpointsを設定します。これがVMware ESXiホストがストレージプールとVVOLで接続するのに必要なエンドポイントです。「Storage -> VMware -> Protocol Endpoints」と進んで、「＋」をクリックしウィザードを開きます。

39

Procotol Endpointsとして使用するNASを選択します。先ほど作成したNASを選択します。このNFSプロトコルが有効化されたNASを使い、Endpointを作成します。

40

次にProtocol Endpointsの名前を決めます。わかりやすい名前にします。

41

接続先のESXiホストを選択します。ここではすべて選択していますが、VVOLとして接続できるのはESXi 6.0です。次にサマリ画面が表示されるのでFinishをクリックします。

43

Protocol Endpointsが作成されると左のような一覧画面になります。

ここまでVVOLに必要なストレージ設定を紹介しました。次回の記事ではついにVVOLの設定を行います。
EMC vVNXでVVOLを用意してみる【その３：VVOLを設定してみる】

タグ: , ,

EMC vVNXでVVOLを用意してみる【その１：インストールしてみる】

投稿日: 2015年10月21日 クライム
VMware vSphere

VMware vSphere環境では、データストアとして、ローカルのHDD、SSD、共有のSAN、あるいはNFSなど、さまざまなストレージが使用されています。
しかし、最近ではSoftware-Defined Storageということで、VMware vSANや、弊社取扱い製品のMaxtaなど、複数のストレージを統合し、仮想的に１つのストレージとして扱う技術を使いデータストアを用意されている方も増えてきています。

そんななか、SDSの一種として、VVOLというストレージ技術がvSphere 6.0より搭載されるようになりました。このVVOLではそれまでストレージ上ではLUN単位で複数の仮想マシンをまとめて管理していたものを、１つの仮想マシンにつき１つのLUNに割り当てられるようになるAPIです。
この際、仮想マシンごとにストレージポリシーを割り当てられるため、サービスレベルも細かく調整が可能となります。

このVVOLに対応したストレージは複数出てきていますが、今回、その中からEMC社のストレージ製品「VNX」の仮想アプラインス版である「vVNX」を使いVVOLストレージを作成します。
vVNXはEMCのVNXストレージの動作をエミュレートしている仮想アプライアンスで、SANストレージとしてESXiに接続することが可能です。
現在は、vVNX Community Editionという検証用途であれば無期限・無償にて利用できるエディション（サポートなし）が配布されていますので、それを使います。

今回はVVOLの導入・設定までの流れを3回の記事に分けてスクリーンショット付きで紹介します。
1回目の本記事はvVNXのインストール完了までとなります。

まずダウンロードするvVNXですが、これには注意するべき点があります。
というのも配布されているvVNXには3.1.2と3.1.4という2つのバージョンがあります。
このうち、VVOLに対応しているvVNXは3.1.4となります。

VVols_vVNX

こちらのvVNXはOVAテンプレート形式のファイルで配布されており、2GB強のサイズがあります。
また、必要とするリソース量も多いため、余裕がある検証用の仮想化ホストを用意する必要があります。

さて、ダウンロードした後はテンプレートを展開する必要があります。
この展開作業は3.1.2のvVNXと同一の手順となります。
特に迷うことはありませんが、ネットワールド様のブログにて手順が紹介されています。
Virtual VNXマスターへの道：その①
なお、VVOLとして展開する場合、固定IPアドレスが最低で4つ必要となります。
（管理用コンソールに１つ、iSCSIポートとして２つ、Protocol Endpoint用NAS（後述）として１つ）

このOVAの展開ですが、Web Clientだと展開した後、仮想マシンの起動途中で止まってしまうという問題が起きることがありますので、なるべくvSphere Clientから展開したほうが良いです。

vvol_vVNX_ipaddress

無事に起動すると、すでにVMware Toolsが入っているため、Client上でIPアドレスの確認が可能です。

emc_vvnx_login

この管理用IPアドレスにウェブブラウザでアクセスすると、次のログイン画面が表示されるので、初期設定であるadmin/Password123#と入力します。

01

すると、ウィザードがブラウザ画面上に現れるので、設定を進めていきます。
まずはパスワードの変更を求められるので、変更します。
次にライセンスキーのインストールを求められます。UUIDをメモします。なおこのUUIDは展開するごとに別のものが割り当てられます。

vvnx_uuid

vVNXダウンロードページにあるRegister Your VVols: License Your System for Full Functionalityにアクセスします。表示されているUUIDを入力し、製品リストから「Vvol Tech Preview for vVNX」を選択してSUBMITをクリックするとライセンスキーファイルのダウンロード画面が表示されるのでダウンロードし、そのファイルをInstall Licenseから投入します。

以降DNSサーバおよびNTPサーバを設定する画面がありますが、あとからでも設定可能ですので、必要がなければそのままNextを押してスキップします。

05

ストレージプールの作成画面ですが、これも後で設定可能ですので、ここではスキップします。

06

iSCSIインターフェースの設定画面です。「＋」をクリックして、ネットワークインターフェースの設定を２つ行ってください。

この後、NAS Serverの設定画面になりますが、これも後で設定可能ですので、ここではスキップします。

09

設定概要が表示されるので問題がなければFinishを押して設定します。

10

左のような画面になれば設定は完了です。

emc_unisphere_toppage_fullwidth

管理コンソールEMC Unisphereの画面は全面的にHTMLで作られており、Flashプラグインなどは不要です。デザインも扱いやすく作られており、操作も便利に行えます。

次回はVVOLに必要なvVNX上でのストレージ設定である、ストレージプールの作成、NASサーバの作成、ESXiホストの認識設定、そしてProtocol Endpointsの設定の方法を紹介します。
EMC vVNXでVVOLを用意してみる【その２：ストレージを設定してみる】

タグ: , ,

最先端ストレージのアーキテクチャガイド：ホワイトペーパ紹介

投稿日: 2015年9月15日 クライム
VMware vSphere クラウド・仮想インフラ

従来のストレージ アーキテクチャでは、仮想化による同一のストレージリソースに対する複数のI/O統合やスケールアウトなアプリケーションによる負荷の増大に対応しきれず、フラッシュを活用するための特別な処理を行えないため、それに合わせてパフォーマンスを向上させることが難しくなっています。

これに伴い、現在、様々な新しいストレージアーキテクチャが登場しています。例えばフラッシュに必要な特別な処理を実装した、オールフラッシュ アレイ、フラッシュをパフォーマンス向上のために利用するハイブリッド アレイ、サーバサイドのリソースを活用するハイパーコンバージド インフラストラクチャなどです。

ただ、これらのストレージアーキテクチャには様々な利点と問題点があり、本当に必要とするアーキテクチャを採用する必要があります。

単純にストレージ アレイのパフォーマンス向上といった面ではハイブリッド アレイを新たに購入するというアプローチもありますが、それでは依然として従来のアーキテクチャの課題を解決することは難しく、オールフラッシュ アレイはあまりにも高価です。
そこでハイパーコンバージド インフラストラクチャを採用し、サーバサイドのリソースを活用するといったアプローチも考えられますが、これを採用するためには既存環境を置き換える必要があります。
ストレージアーキテクチャ

そこで、サーバサイドのリソースを活用し、パフォーマンスの向上を行おうと考える企業の多くは既存環境に大幅な変更を行わなくとも、これを可能にするソリューションを求めています。

これを実現することが可能なソリューションがストレージ アクセラレーションです。サーバサイドの汎用的なリソースを活用し、既存のストレージ アレイの容量とパフォーマンスを分けて管理できます。また、既存インフラストラクチャへの投資を無駄にすることもあります。

従来のストレージアーキテクチャのお悩みの方、新たにストレージ アレイの購入やハイパーコンバージドインフラストラクチャへの導入を検討中の方は是非、以下のホワイトペーパーをご覧ください。より詳細に従来アーキテクチャでの問題点や各ストレージアーキテクチャの利点や課題を解説しています。

最先端ストレージのアーキテクチャガイド
表紙
・従来のアーキテクチャ
・現在の複雑な構成：仮想化、スケールアウト、クラウド
・ハイブリッド アレイ
・オールフラッシュ アレイ
・ハイパーコンバージド インフラストラクチャ
・ストレージ アクセラレーション
・INFINIOストレージ アクセラレーションプラットフォーム