« 2016年7月 | メイン | 2016年9月 »

2016年8月

2016/08/31

PernixDataはNutanixファミリーに合流しました

本ブログエントリーはNutanix社による買収が明らかとなったPernixData社のCEOであるPoojan Kumar氏のブログ記事を翻訳しています。 

本記事の原文はPernixData Joins the Nutanix familyで閲覧可能です。

ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら

PernixData社がNutanixファミリーに合流することをアナウンスすることに身震いを禁じえません。このPernixDataを創業してからはまさに素晴らしい4年半でした。我々の従業員、お客様、パートナー、PernixProの皆さん、PernixPrimeの皆さん、そしてアナリストやブロガー、そしてもっともっと多くの皆さんなくしてはこれはあり得なかったでしょう。

多くの人は御存知の通り、Nutanixはエンタープライズクラウド分野におけるリーダーで、業界に強力な影響力を及ぼしています。我々は彼らと合流して、次世代のデータセンタをつくり上げるというビジョンを戦略的に分担していくことを考える興奮を禁じえません。2つの会社の間のシナジー、文化、チーム、優れた製品に対するコミットメント詳細への洞察、そして最後に大きな目標までもが本当に素晴らしいものです。我々2つの会社が一緒になることは1+1が3になるようなものだと考えています。

まだ、どのようにPernixDataのテクノロジーがNutanixファミリーと統合されていくのかをアナウンスすることは出来ませんが、我々の既存のお客様はいつものとおり、サポートを継続して受けていただくことが可能で、それはいつものPernixDataのワールドワイドクラスのサポート組織によって提供されます。(※訳注 : 国内のPernixDataのお客様はTEC-WORLDを利用して日本語でのサポートを継続して受けていただくことが可能です。) そして、今や、そのサポートチームはNutanixのサポート組織によって支えられることになります。

我々はNutanixの拡張性と分散性を活用して、我々のテクノロジーをもっと多くの人々に早くお届け出来る様になると考えています。この2つの要素が一緒になることで、お客様のエンタープライズクラウドへの旅路を加速することをお手伝いすることが出来るようになります。

全ての皆様と皆様からのサポートに大変感謝しています。そして、我々の旅の次なる章への前進を楽しみに見ていてください。

Poojan Kumar

Co-founder/CEO, PernixData

記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw) 今後は (@Networld_NTNX)

2016/08/30

VMworld 2016 Day1 General Session 国内最速レポート

皆さん こんにちは
5年連続5回目のVMworldに参加中の工藤です。
今年は私から現在開催中のVMworld 2016の初日のGeneral Sessionの速報をお送りします。

Image_2

このままクラウドの普及が続くと2021年に漸くトラディショナルなインフラが50%になる予測を披露しました。

Image

そんなクラウドとオンプレミスが共存するIT基盤においてFreedom とControlの両立を実現するHybrid Cloudを提供するのがVMwareのミッションであると発表されました。

そんなHybrid Cloudを実現するCross Cloud Archtectureとして以下のような発表がありました。

  • 統合基盤ソフトウェア「Cloud Foundation」の発表
  • マルチクラウド管理のSaaS「Cross-Cloud Services」の発表

今回は統合基盤ソフトウェア「Cloud Foundation」について紹介してみたいと思います。

■「Cloud Foundation」の発表
ITmediaの三木さんが既にこちらで紹介されていますが、最近のトレンドであるHyper Coverged Infrastructureの新しいモデルとして「Cloud Foundation」が発表されました。既にこちらに製品ページから発表された内容を確認することができます。

■「Cloud Foundation」って何?

「Cloud Foundation」は一言でいうと、vSphere + Virtual SAN + NSX + SDDC Managerで構成されたソフトウェア群の名称です。従来「EVO SDDC」として提供されていたものを置き換えるものとなります。以前のEVO:RAIL、現在のVSAN Ready NodeやEMC VxRAILのようなアプライアンスはvSphere + VSANだけの統合でしたが、NSXまで統合されることによってネットワークまで含めた提供のなっている点が異なります。Hyper Converged Infrastructure業界のリーダーであるNutanix社の掲げる「Enterprise Cloud」のビジョンとも似ていて、パブリッククラウドのようにシンプルにするにはオンプレミスのインフラもシンプルにする必要があり、それをソフトウェアで実現するVMware社のソリューションともいえるのはないでしょうか。

■「Cloud Foundation」ってソフトウェア単体で構築するのと何が違うの?

「Cloud Foundation」で追加された「SDDC Manager」は現在のところ物理リソースを管理して、サーバ仮想化の基盤(VI)と仮想デスクトップの基盤(VDI)を裏で展開を自動化し用途に応じて払いだすことができるそうです。そして展開されたソフトウェアコンポーネントを含むソフトウェア群のアップデートのライフサイクル管理が提供されます。

Sddcmanager_2

また今後Cloud FoundationがvRealize AutomationやvRealize Business、Integrated OpenStackに対応してDevOPSの基盤やvCloud Foundationのコスト管理などの機能追加がされる予定です。

Sddc

■「Cloud Foundation」はどうやって提供されるの?

今までのHyper Converged Infrastructureに対するVMware社のアプローチ同様VMware社からはソフトウェアだけを提供し、エコパートナーからHyper Converged Infrastructureとして提供される形をとっています。現在3つの提供形態が予定されています。

  1. 統合アプライアンスとしての提供
  2. Ready Nodeの提供
  3. パブリッククラウドとの連携

統合アプライアンスとしてはEMC社よりVCE VxRack1000 SDDCとして提供がされる予定です。Ready NodeとしてDELL社、HPE社、Quanta社より提供がされる予定です。そして最後のパブリッククラウドとの連携ではIBM Softlayer上で提供された後、vCloud Air、vCloud Air Networkが追加されていく予定です。

■まとめ

Cloud Foundationを実現することで、オンプレミスとパブリッククラウドをまたいだハイブリッドクラウドを実現することができるようになります。今回のGeneral Sessionで発表されたCross Cloud Serviceもこうした基盤がある前提になるような気がしています。オンプレミスのインフラをシンプルにするCloud Foundationに皆様ご注目ください。

また9/14,18にVMworldの内容をまとめてわかりやすく解説するフィードバックセミナーを予定しております。興味のある方は是非こちらにいらっしゃってください。

VMworld 2016 フィードバックセミナーhttps://networld.smartseminar.jp/public/seminar/view/668

次回はこのCross Cloud Serviceについて紹介していきたいと思います。

2016/08/22

[最新鋭、IBM FlashSystem A9000大解剖!]

IBMの最新鋭の超高速フラッシュストレージ FlashSystem A9000をお借りしちゃいましたっ。

実際に動かしてみようっ♪


いきなりですが、「実際に動かした結果を速く視たいんだけどなぁ♪」 とボスから指令がっ!!
ということで簡単な環境をつくって少しだけ試してみましたっ♪

さっそく、サクッと図のような環境をセットアップ~っ♪

A9000test1

で、何をしようか・・・・・♪

とりあえず、代表的な機能のテストをやってみようかなっ。実機でっ♪


重複排除って本当に効くの!?

**A9000上、単一ボリューム内で複製をした場合**

1個のデータストア内でVMを複製してみましたっ♪

1:ESXiのデータストア用にA9000上に約1TBのボリュームを1個作成
2:このボリューム内に1台目の仮想マシンを作成
3:同じボリューム内に1台目の仮想マシンのクローンを作成して2台目を作成
4:同じボリューム内に、残りの仮想マシンのクローンを作成して合計10台を展開
*(仮想マシンには、WindowsServer2012R2をインストールしました。)

Ffx417

その結果がこちらっ♪

姐さんっ!重複排除、効いてますぜっ!!
(約98パーセントの排除率を確認できました。)

Clonevm


続いてぇ~っ♪

**A9000上、複数のボリューム上に同じデータを複製した場合**

10台のVMそれぞれにRDM(ローデバイスマッピング)の領域を追加してデータをコピーしてみたっ♪

1:A9000上に50GBのボリュームを10個追加作成する。
2:先ほど作成した10台のVMそれぞれに1個づつRDM領域としてDiskを追加する。
3:10台中1台目のVMのRDM領域にダミーデータを書き込む。
4:他のVMにもそのダミーデータをコピーする。
*(ダミーデータは合計約10GBの、pdfやpptなど単体では圧縮の利き辛いアトランダムなドキュメントファイル群です。)

Ffx418

兄貴っ、やはり重複排除、効いてますぜっ!!
(2台目以降の重複排除率が9個平均で約88.4パーセントという結果になりましたっ♪)
おやおや~っ、これってVDI用途なんかには超絶効果が期待できそうじゃなイカっ!!(マジで期待していいと思うっ♪)

Qq

★この「重複排除」はA9000/A9000R上の単一ボリューム内だけでなく複数のボリューム間であってもその効果を実感できるんですっ!



あっ!、そういえば!!圧縮はどうなのよっ?

ということで、実際にデータベースを動かして試してみましたっ♪。
1:今度はサーバーのローカルに3台のVMを作成するっ
2:A9000上に10TBのボリューム3個を作成するっ
3:3台のVMそれぞれに1個ずつRDMでディスクを追加っ
4:RDMの領域にサンプルDBをロードするっ♪
*(各DBの最終的なファイルサイズは平均約1.7TB)

Dbb

ボスっ!重複排除の効きにくいDBのようなファイルでも圧縮効いてますぜっ!!
ファイルサイズ平均1.7TBの状態
(圧縮率3台平均で約47パーセント)

Final01


今回は短時間で行ったほんの一例ですが、どおやらデータ削減の効果は大いに期待できそうであるっ♪

他にも「マルチテナンシーのQoSの効果っ♪」や、「超絶IO負荷地獄」、「帯域の鉄人」、「パターン排除の飽くなき削減」
など、やってみたい事はいっぱいあるので、今後少しづつでもご報告できればと思いますっ♪

次回は、「筆者もびっくり!何があってもデータは守りきるっ!究極の電源機構っ!!」


by:まいけル

2016/08/18

サンドボックス化された完全なマネージドOpenStackのテストドライブ(Platform9を体験してみたい方!お待たせ致しました!)

本記事の原文:Test-drive Fully Managed OpenStack in a Sandboxの公開は2016年の8月5日です。現時点では機能が拡張されたり、改善されている場合がございますのでご注意ください。

Platform9製品詳細についてはこちら

Platform9はSaaSベースのマネージドサービスを利用して、OpenStackによるプライベートクラウドの展開、稼働、管理そして拡張をご提供しています。展開は数分で済みます。Platform9はSaaSレイヤーにOpenStackのコントロールプレーンを稼働させ、皆様にやっていただくことはKVMホストへエージェントをインストールするか、vSphere環境に(仮想)アプライアンスを動作させるだけです。

展開は非常に簡単で数分で終わりますが、我々はそれをもっとシンプルにし、Platform9をご自身の環境でインストールする前に試してみていただきたいと思っていました。今回、自由に探検いただけるOpenStackのサンドボックス環境をアナウンスできることを誇りに大変喜ばしく思います!

サンドボックスへのアクセスはhttp://www.platform9.comへアクセスし、サインアップしてください。

ログインを終えると、多くはありませんが組み込みのGlanceイメージと仮想マシンのフレイバーにアクセスできるテナントのロールが割り振られます。ここから簡単に仮想マシンを展開し、コンソールにアクセスしたりや起動、シャットダウン、仮想マシンの構成変更などのデイ2(展開が終わった翌日)の運用を試してみていただくことが可能です。ユーザーインターフェイスから殆どのワークフローを実行することが可能となっています。これはサンドボックス環境ですから、ホストの追加やルーターの追加、新しいGlanceイメージのアップロードなどの特定の運用は行えません。我々はサンドボックス環境へ随時新しい機能を加えていきます。

サンドボックスは最初のログインから4時間だけ利用することが可能です。もし、もっと時間をかけてPlatform9 Managed OpenStackインフラストラクチャを試してみたいと言う場合にはいつでもフリートライアルへアクセスいただくことが可能です。

さぁ、まずhttp://www.platform9.comまでアクセスを!

冒険を楽しんでください!

訳注: リソース上の都合で国内ではフリートライアルへのお申し込みを制限しておりました。今回利用可能になったテストドライブ(http://www.platform9.com)はこの制限を受けません。誰でも、いつでも、Platform9 Managed OpenStack環境を4時間好きなように利用することが可能です。上の記事でも述べられている通り、テナントロールでのアクセスを想定しているため、完全な管理者アクセスにて評価を行いたいという場合には以下のWebセミナーへお申し込みください。

【Webセミナー】Platform9 Managed OpenStack Web&デモセミナー
話題!日本上陸直後のPlatform9 Managed OpenStackを徹底解説 & デモを実施

昨年、OpenStack Summit 東京での開催、先日開催OpenStack Summit Days Tokyo 2016の大成功、大規模な導入事例発表など、OpenStackの熱気はいよいよ日本国内へも押し寄せてきています。
しかし、OpenStackはオープンソースプロジェクトでそのものはフリーで提供されていますが、そもそもインストールが難しい、運用管理していく手間とコストが膨大になる、アップグレードがうまくいかないなど、一般的な企業のお客さまにとっては多くのハードルを抱えています。

本セミナーではOpenStackの5つの展開方法とそのメリット・デメリットを上げた上で、
Platform9社が提供するユニークなOpenStack-as-a-serviceについてご紹介致します。
これまでになかったアプローチでのOpenStackの利用開始、運用、そしてその効果についてあますところなくお伝え致します。
本セミナーへご参加方にのみ、Platform9 Managed OpenStackのフリートライアルアカウントをお渡し致します。是非奮ってご参加ください。

さらにここまで読んでくださった方向けのオトク情報!!

@Networld_pf9 アカウントをフォローした上で、本セミナーの登録ページへのツイートをリツイートしてくださった方にはセミナー実施前にも優先的にフリートライアルの割当を行っております。

記事責任者 マーケティング本部 三好哲生 (@Networld_pf9)

2016/08/10

HyperFlexのバックアップはVeeamにお任せ!

先月、弊社ではCisco HyperFlexとVeeamの共同セミナーを全国4拠点で開催し、ニュースサイトでも紹介されました!
http://biz.bcnranking.jp/article/news/1607/160711_142672.html

そこで、セミナーにご参加いただいた方には重複する内容になりますが、今回はVeeam Backup & Replicationを使用したHyperFlex環境のバックアップについてご紹介させていただきます。


①  HyperFlexとは?

こちらでご存じの方もいるかもしれませんが、今年3月に発表されたCiscoのハイパーコンバージドインフラ製品で、Fabric Interconnect + UCSサーバのハードウェアで構成され、SDS(Software Defined Storage)+管理ツールが含まれます。SDSはSpringpathのものを使用しており、重複排除と圧縮が標準機能になっています。

Hxveeam1

②  何故、HyperFlex+Veeam?

HyperFlexはVMwareの仮想環境に特化したハイパーコンバージドインフラ製品であり、Veeamも仮想環境に特化したバックアップ製品で相性ピッタリの組み合わせです。また、HyperFlexはUCSのノードを追加することでスケールアウトに対応できますが、Veeamもバックアップ処理を行うプロキシサーバやバックアップ保存先となるリポジトリを追加することでHyperFlexにあわせてスケールアウトに対応できます。

Hxveeam2_2これは弊社の勝手な思いつきの組み合わせではなく、Cisco社とVeeam社はアライアンスが組まれており、既に海外ではHyperFlexとVeeamがセットになったアプライアンス製品も販売されています。

https://www.cisco.com/c/dam/en/us/products/collateral/servers-unified-computing/ucs-c-series-rack-servers/whitepaper-CiscoVeeam.pdf

Hxveeam3_2

③  VeeamでHyperFlexをバックアップしてみよう!

物理のVeeamサーバを用意して、NBDモード(10Gネットワーク経由)で、1つのバックアップジョブで仮想マシン(Windows 2012 R2/100GBのVMDK)を1台/2台/3台/6台/9台/12台と台数を変えて、HyperFlex上の仮想マシンをバックアップしてみました。

【検証構成】

Hxveeam4_6

Hxveeam4a_5 

その結果が下の表です。

Hxveeam5

注:

※バックアップ時間は3回実行しての平均値になります。

※仮想マシンはHyperFlexのクローン機能を使用して用意しました。

※仮想マシンは起動した状態であるため、バックアップ容量はログなどにより差異があります。

※仮想マシンは各ESXiホストに均等に配置しております。(例)12VMの場合は、1ESXiホストに4VM配置

※プロキシサーバの同時タスク数(デフォルト:2)、リポジトリの同時タスク数(デフォルト:4)、データストア毎のスナップショット数(デフォルト:4)の制限は解除しております。

※弊社の検証環境での値であり、全ての環境で同等の数値が出ることを保証するものではありません。

 

1台だけでバックアップした時間(4分弱)も十分早いですが、台数を増やしていくことで、1VMあたりの時間が一層短くなっていきました。6台以上の場合は、なんと!1VMあたり、1分を切る高速バックアップです!!Thin DiskとThick Diskも数秒程度の違いしかありません。

SpringpathのSDSが重複排除・圧縮が標準機能ということで、バックアップ(読み取り)に時間がかかるのでは?と心配した方もいるかもしれませんが、安心してください。こんなに高速にバックアップすることができます!! 

あまりのバックアップの速さに信じられない方は、下記の無償の製品評価版で試して、第3者の厳しい目で判断してください。

Veeam Backup & Replication製品

Veeam製品評価版入手手順

評価ガイド(日本語版)

HyperFlex+Veeamは安心・確実な組み合わせです。日本でHyperFlexとVeeamの両方を販売できるのはネットワールドだけですので、HyperFlexのバックアップを検討している方は、お気軽に弊社までご相談ください。HyperFlexに限らず、ハイパーコンバージドインフラ環境のバックアップにお悩みの方からのご相談もお待ちしております。

担当:臼井

Platform9上にPlatform9を動作させる

本記事の原文:Running Platform9 on Platform9の公開は2015年の2月3日です。現時点では機能が拡張されたり、改善されている場合がございますのでご注意ください。

Platform9製品詳細についてはこちら

僕らも自分のケーキを食べてもいい? 数ヶ月のコンセプトから本稼働環境での利用に至るまでの開発を終えた我々が、自分自身と我々のプライベートなPlatform9 Managed OpenStackのインスタンスに問い続けた質問です。我々はこれを親しみの意味を込めて「ドッグフード」と呼び、日々のビジネス ー継続的な統合と検証ー の大部分で活用しています。

少し前置きを。ご存じの方もおられると思いますが、Platform9はエンタープライズの顧客がご自身のインフラストラクチャのリソースを集約し、柔軟なプールへと変えるようなビジネスをしています。プール化されたインフラは最新鋭のオープンソース・ソフトウェアを利用してPlatform9によって稼働、管理されおり、サービスとして提供されています。マネージドOpenStack、これが我々の最初の製品はこのモデルです。そして、顧客に社内のサーバ、ストレージ、そしてネットワークを利用しながら、完全なOpenStackで構成されたプライベートクラウドを提供します。しかも、複雑なソフトウェアのインストール、構成、拡張、バックアップ、アップグレードは顧客からは見えません。これをどうやって実現する? クラウドのメタデータとコントロールソフトウェアを展開ユニット(Deployment Unit - DU)と呼ばれる要素の集合としてホスティングします。セキュリティのために、それぞれの顧客は自分自身の、完全に隔離されたDUを割当て、それをPlatform9が管理します。

最も単純な形では、DUはデータベースとGlanceとNovaの管理要素(API、スケジューラー、コンダクター、ネットワーク)のOpenStackコントローラーサービス群からなります。顧客のニーズが大きくなるにつれ、DUは複数のサーバーへと拡張することが出来、さらには地理的にも広がっていくことが出来ます。これによってパフォーマンスと可用性を上げていくことが出来ます。簡単のため、この記事では1サーバで構成されたDUにフォーカスします。我々はDUがほとんどあらゆるコンピューティングインフラストラクチャ上で動作するように設計しました。例えばパブリッククラウドや自分自身のデータセンタで動作します。若いソフトウェアカンパニーと同様、我々も必要なコンピューティングを得るためにAmazon Web Services(AWS)を利用することにしました。


  +------------------------------------------------------------------+
  |               展開ユニット (Deployment Unit - DU)                | 
  | +-----------------+ +-------------------------+ +--------------+ | 
  | | PF9コントローラ | | OpenStackコントローラ群 | | データベース | | 
  | +-----------------+ +-------------------------+ +--------------+ | 
  +------------------------------------------------------------------+
            /                              
           /                                
          /          インターネット              
- - - - -/- - - - - - - - - - - - - - - - - -  - - - - - - - - - - - - - -
        /          顧客のイントラネット           
       /                                        
+--------------------------------------------------------+    +----------+
| +------------------------+ +-------------------------+ |    |          |
| | PF9 ホストエージェント | | OpenStackエージェント群 | |    |          |
| +------------------------+ +-------------------------+ |....|          |
|                         ホスト 1                       |    | ホスト N |
+--------------------------------------------------------+    +----------+

多くの近年のクラウドソフトウェアの設計に習い、OpenStackはコントローラ/スレーブのアーキテクチャを採用し、インフラストラクチャの要素を管理・監視します。例えば、コンピューティングホストの管理のため、OpenStack Novaはnova-computeと呼ばえるスレーブエージェントを各管理対象ホストに配置します。最初のManaged OpenStackのリリースでは、ホストはサポートされているLinuxディストリビューション(現在はUbuntu 12とCentOS6 ※訳注原文記事執筆当時の情報です)が動作していればどんなホストでも構いません。コンピューティングキャパシティをプライベートクラウドに追加する際には、顧客はまず、それぞれのホストにゼロコンフィグレーションのPlatform9のホストエージェントを展開します。それぞれのホストエージェントは自身がインストールされているホストをセキュアなアウトバウンド接続を利用して顧客の展開ユニットに登録します。承認(authorization)と呼ばれるステップを通じて承認されると、エージェントはDUに対してホストにとって適切なソフトウェアや構成を問い合わせ、自動的にダウンロードしてインストールし、それらのソフトウェアの構成を行います。特定のホストに適切なソフトウェアの分配を決定する際にはホストにアサインされた役割(role)によって決定します。例えば、普通はコンピューティングホストはnova-computeエージェントを受け取ります。一方で、イメージライブラリホストはPlatform9が特別にパッケージしたソフトウェアを受け取り、それをイメージキャッシングサーバとして利用します。一つのホストが複数のロールを持つことも可能です。まとめると、図1になります。これが通常の顧客の目線から見たManaged OpenStackの展開の様子です。

継続的な統合と検証

Platform9のトッププライオリティは製品を高い品質に保つことです。Managed OpenStack(MO)を検証するため、我々は継続的なビルド&統合サーバ(Teamcity)を用いて、要素/機能検証と統合テストを組み合わせて実施しています。我々は大抵は1つのgitリポジトリを機能コンポーネントごとにメンテナンスしています。Managed OpenStackのリリースのために必要なバイナリを生成する際に、全体で12ほどのリポジトリからのコードのビルドと検証が必要です。リポジトリのうち、いくつかはPlatform9ヴァージョンのOpenStackコンポーネントですし、残りは完全なPlatform9だけのソースコードです。標準のOpenStackのコードは広範な機能検証が含まれており、OpenStackのリポジトリにコードがチェックインする度に検証コードが動作します。

統合テストはもっと複雑で、製品全体を検証し、さらにコンポーネントの展開や接続までを最終形として実施する工程までを含むため、完了までに長い時間がかかります。Managed OpenStackの展開トポロジは通常のOpenStackとは異なっていますので、Platform9固有のシナリオー例えば、ユーザーの認証、ホストの認証、イメージライブラリからのインスタンスの展開、ネットワーク機能、NFSのサポートーでの検証のために多くの統合検証コードをスクラッチから書き起こしました。これを書いている最中にも、17の大きな統合テストが成功に終わることをまっています。上手く行けばManaged OpenStackのビルドがうまくいくということです。それぞれの検証は自分自身で1~15ホストー平均的には大体3ホストーの展開ユニットを作成し、多くの項目に渡る、小さな検証を実施しています。標準では検証用の展開ユニットは1台のコンピューティングインスタンスからなっています。大抵の1つのMOで17の展開ユニットを展開しますので 3 x 17 ~= 50ホストのインスタンスが稼働することになります。ピークの時期になると、CI(継続的な統合)サーバは1日に10回はMOの作成を行います。つまり、170の展開ユニットで500ホストインスタンスを稼働させているということになります。

仮想化環境上に作られた検証インフラストラクチャ

上で述べてきた検証の負荷の推測はあくまで本日(訳注:記事執筆当時)のスナップショットです。もちろん、初期には負荷はずっと軽かったです。他の若い会社と同様に、我々のニーズは最初の一年間で劇的に成長しました、そして、幾つもの失敗の中から多くの教訓を学んだのです。我々の検証のニーズに適合するために、今日我々が検証インスタンスを動作させているインフラストラクチャとその検証を自動化している方法は以下のテーブルにまとめてあるように進化してきました。興味を引くポイントは我々がどのように仮想化を活用し、ソフトウェアのレイヤーを積み上げているかです。

Fig008

フェーズ 1

当初、当然のように我々は検証環境を実際に利用される環境にできるだけ近い形で作成しました。つまり、展開ユニットはAWS上で、Platform9のささやかなデータセンタ内におかれた実際のサーバをコンピューティングホストとして利用します。これはたいていのお客様が経験するであろうセットアップの環境を再現するためでした。このアプローチで我々は2つの問題に突き当たります。一つ目はホストが実際のCentOSまたはUbuntuが動作しているLinuxコンピュータですから、それぞれの結合テストの前に初期状態に復元するためのスクリプトを開発しなくてはならなかったことです。「bit rot(訳注:長時間にわたってコンピュータを使うことでメモリやデータに小さな変化が積み重なり、不安定になること)」と呼ばれる概念をご存知の方もおられると思いますが、これは言うほど簡単なことではありません。様々な努力にもかかわらず、何度もサーバはコントロール不能になり、検証の結果は一環したものにならず、バグを診断するのが難しくなってしまいました。もっと大きな問題は拡張性です : 単純に、我々は増え続ける検証の負荷に見合うだけの十分なハードウェアを購入できない状況になったのです。


   +----------------------------------------------------------+
 2 | 統合検証中に Nova インスタンスが作成される               |
   +----------------------------------------------------------+
 1 | 物理サーバ上の Linux KVM ホスト上のPF9 compute/imagelib  |
   +————————————————————————————————--------------------------+

フェーズ 2

これらの問題を解決するため、我々は以下の表に表したとおり、PF9ホストが動作する検証インフラストラクチャをハイパーバイザー上(最初はESX、そしてその後KVMが動作するネイティブのLinuxへ変更)の仮想マシンへと変更しました。これによって、入れ子になった仮想化が追加されることになります。つまり仮想ハイパーバイザー(2層目)が仮想マシンとして実際のハイパーバイザー(1層目)の上で動作するということです。ESXとKVMはいずれも入れ子の仮想化をある程度の信頼性を持ってサポートしています。(我々はESXがやっぱり素晴らしいということと、ですが、非常にパフォーマンスが限られている場合、KVMのほうが高速で、やっぱりバグや不可解な動きがあることを発見しました。これはこれだけでもう一つ記事が書けそうです。)


   +----------------------------------------------------------------+
 3 | 統合検証中に Nova インスタンスが作成される                     |
   +----------------------------------------------------------------+
 2 | それぞれの検証毎に PF9 compute/imagelib Linux KVM ホストを作成 |
   +————————————————————————————————--------------------------------+
 1 | 物理サーバ上の ESX または Linux KVM                            |
   +—————————————————————————————————-------------------------------+

我々はPlatform9 Managed OpenStackホスト(2層目)で保持されている仮想マシンの作成や廃棄を担当する機能ライブラリを開発しました。ちょうどこの頃、我々は最初のエンドツーエンドの統合テストの開発を終えました、さらにPythonベースの検証フレームワークの最初のヴァージョンも完成します。社内のTeamcityの統合サーバはコードの変更イベントが発生すればビルドと検証をすべて行ってくれるようになっています。これはコード、ビルド、検証に至るまでエンドツーエンドで自動化統合が完成した時でした。これによって我々はManaged OpenStackの能力を確信もしましたし、品質の期待値を劇的に改善することになります。

フェーズ 3: 「ドッグフード」の誕生

コンポーネントの成熟し、さらに全体がしっかりと結合してくるにつれ、いよいよエンタープライズプロダクトらしくなってきました。我々は適切な機能についてや、適切なユーザーエクスペリエンス、どれだけの信頼性が必要とされるか、セキュリティ、パフォーマンス、拡張性など、数多くの議論を交わしました。終わりのないホワイトボード、ワイヤフレーム、プロトタイプの末に我々は自分たち自身がユーザーにならなければ多くの問題に答えを出すことは出来ないという結論に達しました。言い換えれば、我々の業務(もしくはその大部分)をPlatform9 Managed OpenStack上で行うということです。アメとムチでいうと、これはムチです。

幸運なことに、我々の継続的なビルド、統合、検証にはアメとなりました。我々のごちゃごちゃしているベアメタルのハイパーバイザー(1層目)の上で動作する仮想PF9ホスト(2層目)を管理するためのbashスクリプトやPythonコード群はどんどん複雑化し、維持していくのはまさに悪夢になってきました。我々はテンプレートイメージやホスト間の論理配置、ハイパーバイザーの違い(ESX、CentOS Linux、Ubuntu Linux)に対処出来るだけの綺麗な抽象化を実現していませんでした。こうした問題を解決するためにOpenStackが優れていることは明らかでした。一貫したAPI、CLI、リソースの抽象化、自動配置のアルゴリズムなどが搭載されているからです。

「ドッグフード」プロジェクトはこうして生まれました、そしてこれは今日までに当社がとったエンジニアリングの決断の中で最も大きなものの一つになります。ドッグフードは単にPlatform9 Managed OpenStackの単一のインスタンスです。その展開ユニットは「クラウド」(今はAWS)で動作しており、公開DNSのアドレスでSaaSとして公開されています。全てのコンピューティング、ストレージ、ネットワークリソースはすべてPlatform9のプライベートデータセンタに配置されています。

最初の実装では、我々はPlatform9ハイパーバイザーホストを仮想化していました。会社においてあるハイパーバイザー上で仮想マシンとして動作させていたのです。これは更にスタックに仮想化レイヤを追加することになります。結果は下の図のとおりです。我々はこの追加のレイヤをハードウェアの仮想化サポート機能を完全に利用できるうまい方法を見つけ出すことが出来なかったため、我々は仮想マシン上でQEMUエミュレーションを動作させるしかありませんでした。これはものすごく遅いのです。我々はパフォーマンスが犠牲になるのはわかっていましたが、幾つかの理由でこれを選択しました。まず、仮想(物理の反対という意味で)ドッグフードのハイパーバイザーホストは簡単に作成、管理、廃棄することが出来、それによって必要に応じてホスト数をスケールアップするような操作を簡単に行なえます。2つ目は、このやり方であればすでに持っている稼働率の低いハードウェアを利用できるので、それによって更に物理サーバを追加する際の選択肢も広くなるということです。3つ目は、この時点ではインスタンスを大量に起動する大部分の検証は単にインスタンスがアクティブ状態に到達することを確認するだけのものがほとんどでした。こうした際には検証は早々に終了させることが出来、インスタンスのゲスト内部のスピードはさほど重要ではなかったのです。


   +----------------------------------------------------------------+
 4 | 統合検証中に Nova インスタンスが作成される                     |
   +----------------------------------------------------------------+
 3 | それぞれの検証毎に PF9 compute/imagelib Linux KVM ホストを作成 |
   +----------------------------------------------------------------+
 2 | ドッグフード PF9で管理された仮想の Linux KVM                   |
   +————————————————————————————————--------------------------------+
 1 | 物理サーバで動作する ESX または Linux KVM                      |
   +—————————————————————————————————-------------------------------+

予定通り、我々は自動化のコードを変更してOpenStack Nova APIやCLIを活用できるようにしました。Bashスクリプトは大抵はCLI(nova utilityなど)を利用するために利用されています。そしてPythonコードはRESTをコールする際に利用しています。テンプレートイメージやコンピューティングインスタンスのライフサイクルは一貫した方法で管理できるようになりました。例えば、我々は「刈り込み」というスクリプトを利用して、ビルドの前や、検証の後の時間に古いテンプレートやインスタンスを削除します。様々な理由から、特定のテンプレートやインスタンスを削除せずに保持しておく必要性が出てきます。この機能を実装するため、我々はNovaとGlanceのオブジェクトメタデータにタグを追加し、テンプレートとインスタンスを同じ方法で取り扱うことを実現しました。メタデータのキーに「dont_delete」を追加しておけばよいのです。

フェーズ 4 : ドッグフード 2世代目

ドッグフードの最初の実装はちょっとした統合テストを行えば良いような、会社が小さいタイミングでは充分によく動いてくれました。これはその後の数ヶ月で多くの新しい開発者がチームに入り、多くの機能が追加され、製品の品質を強化するために動作させるビルドや検証の数が爆発的に増えていくにつれ、変わってしまいました。それだけではなく、レイヤ上で動作するQEMUのエミュレーションのパフォーマンスも、もはやインスタンス内のゲストOで動作する興味深い検証などが新しく生まれてきたため、受け入れられなくなってきました。例えば、ほとんどの我々のネットワーク関連の検証はゲストと他のゲスト、または外部システムとの接続を検証します。結果としてOSとして完全にブートが終わるまで待つ必要があります。こうした問題が重なると、ランダムに操作がタイムアウトし、検証に失敗します。これによって我々のエンジニアリングの生産性は地に落ちてしまいました。

我々はパフォーマンスの問題を解決するために、ドッグフードのための専用のハードウェアを購入しました。これによって以下の図のように1つ仮想化レイヤーを削減できました。Linux/KVMをベアメタル(1層目)にインストール、構成しないといけないという柔軟性の喪失は当然のトレードオフです。それを埋め合わせるために、我々はできうる限りのプロセスの自動化を進めました。例えば最初のOSのインストールにはPXEを利用し、Ansibleの構成管理ツールで各ノードに必要なソフトウェア構成を送り込みました。


   +------------------------------------------------------------------+
 3 | 検証中に Nova インスタンスが作成される                           |
   +------------------------------------------------------------------+
 2 | それぞれの検証ごとに PF9 compute/imagelib Linux KVM ホストを作成 |
   +------------------------------------------------------------------+
 1 | ドッグフード PF9 で管理された 物理 Linux KVM サーバ              |
   +————————————————————————————————----------------------------------+

フェーズ 5: ドッグフード 第3世代

ここに至るまで、すべての統合検証環境の展開ユニットは常にパブリッククラウド(AWS)上に展開されています。最初に述べたように、これは実際に利用される環境に可能なかぎり近づけたいという理由からでした。しかし、日々多くの検証のための展開ユニットが生成されるアプローチで、それが100を超えてくると、我々のAWSからの請求書は快適というレベルをあっという間に超えてきました。インスタンスを動作させているというコストからだけでなく、補助的に利用しているEBSストレージ、ネットワーク帯域、RDSデータベースなどからのコストも含まれている結果です。

我々はそれぞれの統合検証が何をしようとしているのかを見直し、殆どの我々の検証はDUが我々のプライベートなインフラストラクチャで動作していたとしてもその価値を失わないという結論に至ります。ですから、我々は検証をAWSではなく、ドッグフード上に展開ユニットを作成するように変換しました。念のためですが、我々はAWSとドッグフードの両方で様々な検証を行っています。我々は徐々に本日我々が利用している構成にシフトしてきました。ドッグフードでは様々な形で我々の日々の継続的なインテグレーションが動作しており、全てのコードのチェックインの度に実行されています。AWSでは定期的に、もっと小規模に実施しています。我々のAWSのためのコストは劇的に下がり、安定しました。しかしながら、ドッグフードを動作させ、適切なハードウェアのリソースを提供し続けるのも時間とお金がかかります。ですから、正確なコスト比較については詳細の分析を待たなければなりません。これが大きな削減になったようなら、またブログの記事を投稿します。

頻繁な更新

ドッグフードは頻繁にアップグレードやアップデートされます。我々のポリシーは実際に顧客のDUへ提供開始する数週間から数ヶ月すべてのコードの変更と昨日の追加を全て展開するというものです。我々はこうした更新を手動で行っています。今後は夜間に自動でアップグレードされるように変更しようと計画しています。

個人利用

加えて、統合検証などで利用するため、我々のプライベートクラウドは各々の従業員向けに個人利用のために開放されています。我々のMacやLinuxマシン上に、novaコマンドラインユーティリティを簡単にインストールし、標準的なOpenStackに接続する環境変数は:


[leb:/devel/pf9-main/testing]$ env|grep OS_
OS_USERNAME=XXXXXXX
OS_PASSWORD=XXXXXXX
OS_AUTH_URL=https://XXXX.platform9.net/keystone/v2.0
OS_TENANT_NAME=service

殆どの開発者は一時的なインスタンスでバグのトラブルシュートや数日で実装できてしまうような機能の開発を行います。他ではもっと長い期間のプロジェクトのために、長時間利用できるインスタンスを作成するか、単に個人の開発環境をホスティングします。我々はOpenStackのタグ機能を利用して、インスタンスやイメージに所有者や目的などの情報についての注釈を入れたりしています。また、頻繁に既存のインスタンスのスナップショットを取っており、試験を動作させる前の状態へと復帰出来るようにしてあります。ユーザーインターフェースについては社内のほとんど半分のユーザーはCLI互換でのアクセスをしていますが、残りの半分は大体はPlatform9のウェブユーザーインターフェイスを利用しているようです。

実体験からの教訓

我々が自分自身のビジネスをPlatform9 Managed OpenStack上で動作させ、ドッグフードを行うと決めた時、とても重要な予見を持っていました。それは、製品に血管があった場合に、我々の会社にすぐにも影響が出てしまうということです。これが我々にとってはトラブルシュート、原因の根本的な解決、問題の迅速な修正についての強いモチベーションになりました。これはまったくもって、予見したとおりでした。製品を日々利用し、ミッションクリティカルなタスクをそれに依存していく中で、我々が検証だけでは様々な理由で見つけられなかった問題を発見することが出来ました。

我々の例は運用が急激にスケールするものです。我々の最初の世代の結合テストでは5ホスト未満でコンピュートインスタンスも1から10インスタンス程度のもので、日々のビルド・検証では数百インスタンス程度の負荷でした。ですが、直ぐに数千インスタンスにも膨れ上がったのです。我々は全てのコンピューティングホストがアイドル状態であっても、それぞれのnova-computeエージェントのサブシステムのうちの幾つかが定期的にNova controllerに状態のアップデート、たとえばKVMの仮想マシンの数やその状態を送るということを知りました。それぞれのこのステータスメッセージはcontrollerに少しずつながら、負荷を加えてゆき、その負荷が充分に大きくなると、公開APIのリクエストの処理をスローダウンさせるということを発見しました。この問題が積み上がっていくと、APIの呼び出しがタイムアウトし、他のビルドタスクの開始に失敗してしまうのです。

他にも、拡張性関連の問題がブートストーム問題の中から燻り出されてきました。上で書いたように、現在製品全体の統合ビルドを行うと、17種類の結合テストが開始されるようになっています。これらのテストは並行して、初期化シーケンスを経て、最終的には50ほどのコンピューティングインスタンスが同時稼働し始めます。我々の統合ビルドサーバは同時に3つのビルドしか同時に走らないように構成されているので、結果としてピークの際には100異常のインスタンスが同時に走ることになります。適切なほどに能力のあるコンピューティングサーバを利用しなかったので、我々はソフトウェアのサブシステムの幾つかが、このスパイクを我々が期待しているほど上手く取り扱うことが出来ないということを発見しました。リクエストがバッチ的に集中する場合、nova-scheduler サービス(インスタンスの配置を決定する)がしばしば同じホスト上に異様に沢山のインスタンスを配置し、リソースを食いつぶしてしまうことがありました。見る限り、ロードバランシングのアルゴリズムがホストの負荷の変化に十分な速さで対応ができていないように見えます。今のところ、これが構成上の問題なのか、設計上の問題なのか追求を進めているという状況です。また、ホストが同時に多くのリクエストを同時に受信するとインスタンスのディスクの処理のための高いCPUとI/Oの負荷の処理で「libguestfs」のサブシステムでタイミングによるバグが出ることも見つけました。これはゲストOSのネットワーク設定を構成する際に利用されます。このバグは修正済みです。

ドッグフードではさほど負荷がかからない、けれども長期にわたって起動し続けるシステムにおいて発生する不具合も見つけ出すことが出来ました。Novaを構成するサービス群は数多くのバックグラウンドタスクを走らせ、メンテナンス用のためのタスクを定期的に活動させます。それぞれのタスクは自分自身でタイマー期間設定を保持しています。あるタスクはその後のタスクの状況に依存している場合があり、その中に長時間に及ぶタイマー設定のタスクがあると数分から、数時間稼働してしまいます。これは時によって非常に見つけにくいバグで発現するのも数日後、しかも特定の状況においてのみ発生するというものです。

不具合や、パフォーマンスの問題を見つける以外にも、日々自身のプロダクトを使うことで製品の至らなさを見つけ、改善することができ、これは我々だけではなく、お客さまにとっても素晴らしい機会となりました。例えば、ウェブインターフェースを利用している時、ある従業員が誤って大きなインスタンスのグループを選択し、それを消してしまうということが有りました。重要なインスタンスがいくつも失われてしまい、こうしたアクシデントが起こらないようにするためにはどうしたらよいか、という議論をすることになります。これに対するソリューションは我々の問題トラッキングシステムの異なるチケットとして様々な形での提案が寄せられます。他と同様に我々は機能追加についてのプライオリティ付を行い、どの製品ヴァージョンでどのリリースを取り込むかを決めます。上で上げた問題では、UIの改善が実装され、ユーザーが大きな破壊操作を行おうとしていることを理解させることが出来るようになりました。最終確認を終え、この変更は既に製品に取り込まれています。製品のAPIレベルで書き込み禁止のフラグを追加で立てるというもっと先進的な改善実装も出来ますが、これは将来のリリースで実装予定です。

将来の方向性

我々はドッグフードの利用範囲を近日中に更に拡張しようと考えています。まずは我々はプロダクトだけでなく、そのワークロードへも拡張しようと考えています。殆どの我々のビルド・統合サーバはベアメタルのハイパーバイザー(ESXとLinux KVM)として動作しており、手動で管理されています。我々はこのミッションクリティカルなシステムを我々自身のプライベートクラウドへと移行させたいと考えています。他の移行候補としてはインフラストラクチャシステムが有ります(例えば、DHCP、DNS、NFS)そして、従業員の個人開発環境などです。

次に、将来のリリースでDockerコンテナのようなLinuxコンテナの管理をサポートする大規模なリリースを予定しています。(訳注:Platform9 Managed Kubernetesとしてリリースされています!)つまり、我々は革新的な方法でコンテナを我々のビジネスに取り入れることが出来るように考えているんです。例としてはまだ検討中ですが、Dockerの大規模スケールでの小さなオーバーヘッドを活用して、何千ものコンピューティングノードのテストを実現したいと考えています。このテクノロジーを利用することで我々のビルドサーバで発生する初期化が不十分であるという問題を解決し、ライフサイクル管理を簡略化したいと考えています。コンテナは常にそれぞれのサーバがクリーンな初期状態で起動することを保証してくれ、しかも高速に起動します。最初のコンテナの管理はマニュアル操作とカスタムのスクリプトで行いますが、直ぐにPlatform9 Managed OpenStackのAPIを利用して出来るようになると思っています。

最後に

自分自身のビジネスをPlatform9 Managed OpenStackで走らせたことは、疑いようもなく我々の製品の改善に役立ちました。日々の面倒な継続的なビルド・検証のシステムをそこへ任せることで、我々は多くの重要な問題を発見し、修正することが出来ましたし、それは人工的な検証シナリオでは見落としてしまうようなものでした。実際の利用シナリオにおける製品の強さと弱さを理解することが出来、そしてユーザーエクスペリエンスと機能の重大なギャップも埋めることが出来ました。これはこの活動の「ケーキ」とも呼べる収穫ですし、そのように意図したとおりとなりました。

この努力によって我々はより俊敏に、そして効率的になったか? 最初の投資コストは正直な話、非常に高いと言わざるをえないものでした。時間、新しいハードウェア、人件費。しかし、今ではシステムが安定し、鼻歌を歌ってくれています。我々はPlatform9 Managed OpenStackが劇的に我々の開発検証の業務を改善し、大規模な自動化を簡単なものにしてくれたと確信することができています。そして、最終的に見ると、今回の努力はパブリッククラウドのためのコストの削減につながりつつ有ります。その通りです、我々は長期の投資の観点から見て危機に脅かされていたのです。このプロジェクトによってそれは解消し、また、我々と我々のお客様のメリットの観点からはより大きな成果を挙げつつあるのです。

記事責任者 マーケティング本部 三好哲生 (@Networld_pf9)

2016/08/08

[最新鋭、IBM FlashSystem A9000を大解剖!]

最近発表されたIBMの最新鋭の超高速フラッシュストレージ FlashSystem A9000をお借りしちゃいましたっ。

グリッド・コントローラーってなあにっ??


分散する複数のコンピューティングリソースを並べて一つに見せる「グリッド」という技術があります。

A9000において、この「グリッド」を構成するのがこの「グリッドコントローラー」ですっ。

Grid_2*A9000は「フラッシュエンクロージャー x1台」+「グリッドコントローラー x3台」 で構成されています。

今をときめく超高速フラッシュストレージを、もっともっといろんな用途に使えないかなぁ・・・

沢山ある答えの一つがこのA9000で、その豊富なストレージ機能が詰め込まれているのが
何を隠そう、この「グリッドコントローラー」なのですっ!

観て通り、このグリッドコントローラーのハードウェア自体は
信頼性高いハイエンドサーバーがベースになっています。
ただでさえ複数のグリッドコントローラーによる冗長を提供しながら
このグリッドコントローラー単体もワンランク上の堅牢性を兼ね備えているんですっ♪。

Gridctl

*こちらがグリッドコントローラーですっ。

例えばグリッドコントローラー本体の冗長電源の、両方の電源供給が
同時に断たれてもシステムのシャットダウンを安全に完了できる機能を有します。

ハイエンドサーバーがベースでありながら、こういっためずらしい機能も搭載しています。
むろんストレージ機器であるフラッシュエンクロージャーにもこういった機能が実装されています。


また、自慢のインラインのデータ削減だって、グリッドコントローラーに搭載される余裕のリソースがあってこそっ!
これは「特定パターンの排除」に始まり、流行の「重複排除」、更にデータの「圧縮」で限りあるストレージのリソースを最大限に利用できるのですっ。

ちなみに圧縮には独自の専用ハードウェアアクセラレーターカードがグリッドコントローラー1機あたりなんと2枚も搭載されているんです!だから速いんです!!
高速な大容量メモリー、複数のマルチコアプロセッサーもそのために搭載されているのですっ♪
とにかく、ありとあらゆる手段でデータ量を削減しまくる!それも高速に!!

とまあ、これもA9000の数ある得意技の一部にすぎませんっ。
XIVで培った豊富なストレージ機能の数々が、このグリッドコントローラーに実装されているのですっ。

なかなかやるでしょ、グリッドコントローラーっ♪


次回は「実際に動かしてみようっ♪」へ続きます♪

*参考資料:英語*
IBM FlashSystem A9000 and IBM FlashSystem A9000R Architecture, Implementation, and Usage



by:まいけル