仮想マシンを動かしたり、Dockerコンテナを扱ったりと、NASをストレージ以外の用途に活用する動きが加速しそうだ。ハイパーバイザー型の仮想化技術を選択したQNAP、コンテナ型仮想化で新機軸を打ち出したSynologyから、今後のNASの方向性を考察してみた。
「いずれは」と思ってはいたものの、このタイミングで、しかも2つの方向性で、この動きが見られるとは思わなかった。
国内でも、知名度が上がってきた海外のNASベンダーであるQNAPとSynologyは、それぞれ既存のNASのラインアップで仮想化技術を実現する新アプリ、新ファームを投入してきた。
もともと、NASは、ローカルに設置する機器の中では、さまざまな技術を貪欲に取り込んできたものの1つだ。
ユーザーの意識がどんどんクラウドへと向かうことに対しての危機感なのか、ローカルに取り残されるであろう最後の機器の使命感なのかはわからないが、スマートフォンなどからもアクセスできるパーソナルクラウドという方向性を打ち出したり、クラウドストレージへのバックアップや同期を可能にしたりしてきた。
グループウェアやCMSを動作させることができるなど、もともとストレージ以外の用途にも使えるマルチユースサーバー的な側面も持っていたが、ついに仮想化というプラットフォームにまで足を踏み入れたことになる。
個人的には、ニヤニヤと笑みがこぼれる一方で、正直なところ、その意図するところを完全には消化しきれない面もある。
とは言え、これで中小のような環境でも、サーバー統合が進むだろうし、クラウドの課金を気にすることなく、しかも一瞬にして開発環境やテスト環境を準備することが可能になることは間違いない。
クラウド上の仮想化サービスを置き替えるのは難しいとしても、果たして併用されるような存在になるのだろうか？ QANPとSynologyの機能の実態に迫ってみよう。
以前も別の記事で同じようなフレーズを使ったが、ここ最近のQNAPの攻めっぷりは目を見張るものがある。
最新ラインアップでSSD向けの製品をリリースしたり、AMDのプロセッサを搭載したモデルをラインアップしたり、Samba4のドメインコントローラー機能を搭載してきたりと、まあ攻めの手を緩めない。
そんなQNAPの攻め手の中でも、特に注目したいのが「Virtualization Station」と呼ばれる仮想化技術だ。
中身は、Linuxユーザーにはなじみのあるクライアントハイパーバイザー型の仮想化技術QEMUをベースにしたものだが、わかりやすいGUI画面が用意されており、仮想マシンを作ったり、スナップショットを作って状態を管理したり、仮想マシンのデスクトップ画面をブラウザで表示して操作することが簡単にできるようになっている。
動作には対応プロセッサが必要となるため、Intel CeleronやCore i、AMDプロセッサ搭載のミドルレンジ以上のモデルに限られるうえ、メモリも最低で2GB以上が要求されるため、機種によってはメモリの増設も必要になる。また、仮想マシンに専用ネットワークを割り当てれば、本体のLANポートの1つを占有し、ネットワークの負荷分散や障害対策をあきらめることになる。しかし、用途によっては、これを乗り越えるだけの価値は十分にある。
おそらくニーズとしてありそうなのは、Windows Serverの統合だろう。Active Directory（AD）ドメインで利用しているWindows Serverや業務アプリケーションを稼働させているWindows ServerをQNAPの仮想マシンとして動作させることで、物理的なサーバーの台数を減らすことができる。
もちろん、Windows Server 2003のサポート期限切れも1つの契機になりそうだ。QNAPのNASの場合、Samba4の搭載でNAS自身をドメインコントローラーとして動作させることが可能となったため、ファイルサーバーの役割だけでなく、ADの役割をSamba4のドメインコントローラーに移行することが、すでに可能になっている。
しかし、完全な互換性を考えると、やはりWindows Serverで運用したいというニーズは少なくない。これに対して、Virtualization Stationを利用すれば、ADは仮想マシンのWindows Server 2012R2に移行し、ファイルサーバーはQNAPというように使い分けつつ、1台のハードウェアで構成することができるわけだ。
同時実行できる仮想マシンの数が機種によって1～8となっていたり（詳細はこちらを参照）、取得できるスナップショットの数が4つまでになっているなどの制約があるが、NASに複数の役割を集約できるメリットは大きいだろう。
このほか、VMwareが提供するVMware Virtual Appliance MarketPlaceも利用可能となっており、あらかじめ構成された仮想マシンを簡単に入手することが可能となっており、さまざまなタイプのサーバーをQNAPに格納することができる。
どちらかというと、ローカルのサーバー統合が当面の主な用途となりそうなので、冒頭で触れたクラウド的な使い方とは言えないが、もちろん開発環境やテスト環境として仮想マシンを活用することなどもできる。どんな用途にも使える仮想マシンを作れる自由度の高さが、QNAPのメリットと言えそうだ。
先日、Synologyの担当者と少し話をする機会があり、仮想化などQNAPに技術で追い上げられているんじゃないか？ という話をした。
その時は、あまり時間がなかったので、明確な回答を聞くことはできなかったのだが、その数日後に、発表されたベータ版のファームウェア（DSM5.2）でDockerのサポートが明らかになった。
いやはや。そんな隠し球があったとは。失礼しました。
というわけで、クライアントハイパーバーザー型の仮想化で攻めるQNAPを、Synologyは少し前から話題になりはじめたコンテナ型仮想化Dockerで迎え撃つという格好になった。
コンテナ型仮想化やDockerについては、ThinkITの「Dockerが注目されている理由を探る」あたりの記事を参照にしてほしいが、その違いを簡単に説明しておこう。
従来のハイパーバイザー型の仮想化は、CPUやメモリ、ハードディスクといったハードウェアをソフトウェアで仮想化する方式だ。このため、起動に時間がかかったり、処理が重かったりするうえ、ハードウェアのリソースも大量に必要になる。
これに対して、コンテナ型の仮想化は、カーネル部分をベースとなるOSと共有しつつ、アプリケーションのみをベースOSから切り離されたリーソース上でプロセスとして実行する。例えば、ベースOS上でsambaを実行するのと同じように、同じベースOS上でコンテナ化されたsambaを実行するようなものと言える。非常におおざっぱに言うと、OSごと仮想化するのか、OSを共有するのかの違いと考えればいいだろう。
コンテナ型の仮想化が注目されているのは、動作に必要なリソースが少なく、起動や処理が高速な点にある。
実際、先のQNAPでは、利用できるCPUやメモリの要件が厳しかったが、SynologyのDockerでは、Atom系のCPUでも動作するうえ、メモリも1GBの標準搭載量で問題なく複数のコンテナを動作させることができる（対応機種などについてはこちらhttps://www.synology.com/en-us/support/beta_dsm_5_2を参照）
また、Docker用のコンテナは、Linuxカーネルを上であれば、ハードウェアに依存せず、基本的にどのような環境でも動作するようになっている。このため、クラウドサービスなどで使われているDockerのコンテナをそのままSynology上で動作させたり、逆にSynologyで稼働させたコンテナをクラウドなどに移行させることも簡単にできる。
ハードウェアが仮想化されるわけではないので、ネットワークをベースOSと共有する必要があるなど、注意が必要な点もある。例えば、ベースOSや各コンテナのIPアドレスは共通となり、22番や80番など、よく使うポートが重複しないように別のポートにマップする必要がある。
同一サーバー上で同じポートを使うサービスを稼働させる場合と異なり、コンテナ内のサービスが使うポートは、80番や22番などの元のままとなるが、外からアクセスする場合は、Dockerによってマップされた別のポートを経由して、コンテナ内の80番や22番にアクセスするイメージだ。
こういったあたりは、ちょっとややこしいと言えばややこしい。
QNAPのようなハイパーバイザー型の仮想化と異なり、Dockerはなじみがないという人もいるかと思うので、少し、手順を追って動作を紹介しておこう。なお、Dockerは、対応するモデルを利用し、現在公開されているDSM 5.2ベータをインストールすることで利用可能になる。ここでは、Dockerがインストールされた状態からの操作を紹介する。
Dockerでは、レジストリと呼ばれる共通の保管場所からイメージを入手する方式となっている（ファイルからも設定可能）。標準ではDockerHubという公開レジストリが利用できるので、ここから検索してイメージをダウンロードする。
例えば、ubuntuやwordpressなどで検索すると、たくさんのイメージが表示される。どれを選んでもかまわないが、Synology上で動作させる場合は、コンソールが使えない点を考慮する必要がある（Docker runの-iや-tが無効）。
イメージによっては、ログインのパスワードなどをあらかじめ指定してコンテナを作成する必要があったり、動作に必要なパラメータの初期設定をインタラクティブに指定する必要があったりするものなどもあるが、こういったイメージは基本的に利用できない。
おすすめは、Dockerのホスティングをサービスとして提供しているtutum（https://www.tutum.co/）向けのイメージだ。「tutum/ubuntu」など、頭に「tutum/」が付けられたイメージは、初期ログイン用のパスワードが自動生成され、ログから参照できるなど、コンソールが使えない環境でも使えるように工夫されている。Synologyで利用するなら、これがおすすめだ。
イメージを入手したら、実際に動作させるためのコンテナを作成する。Dockerでは、イメージをベースに、設定情報や追加ファイルなどの差分をコンテナに記述していくしくみになっている。いわば、これが仮想マシンのような存在だ。
ダウンロードしたイメージを指定して「起動」をクリック。コンテナ名に加えて、ポートを指定する。前述したように、DockerはベースOSとネットワークを共有するので、コンテナ側でSSH用のポート22がそのままだと、ベースOSと同じになってしまう。そこで、コンテナのポート22を49153など別のポートにマップする必要があるわけだ。
と言っても「ポートを自動マップ」にチェックを付けておけば自動的にマップされるので、特に意識する必要はない。
割り当てるリソースは、CPUとメモリのみ可能だが、特に指定しなければ自動的に調整される。このほか、起動パラメータや環境変数なども指定可能だが、基本的にはこれだけでコンテナを作成可能だ。
コンテナを作成できたら起動する。一覧からコンテナを選んでスイッチボタンをクリックすると、即座に起動する。前述したように、コンテナ型ではOSを起動する必要がない。このため、一瞬でコンテナを起動して使えるようになる。
コンテナにアクセスする方法はイメージによってさまざまだが、tutumのubuntuであれば、SSHを利用する。
起動したコンテナの詳細画面を表示すると、自動的にマップされたポートが表示されるので、22番のマップ先（画面では49169）を控えておく。
続いて、ログを確認する。前述したようにtutumのイメージでは、rootのパスワードが自動生成され、ログに出力される仕様になっている。ここで確認したパスワードを使って、ネットワーク上の端末からSSHでアクセスすれば無事にubuntuが使えるというわけだ。
同様にWordpressのイメージであれば、80番のマップ先を確認し、ブラウザでアクセスすれば初期設定ができることになる。
コンテナは、起動や停止再起動が自由にできるだけでなく、必要に応じて「複製」でスナップショットを取得したり、設定をエクスポート/インポートしたりすることもできるようになっている。また、コンテナを「消去（削除だとコンテナ自体がなくなる）」することで、差分情報を消去し、いつでもクリーンなイメージに戻すことも可能だ。
以上、QNAPのVirtualization Station、SynologyのDockerという、NASに新たに搭載された仮想化技術を実際に使ってみたが、どちらもよくできている。
Virtualizationはどちらかというとサーバー統合向きだが、Dockerは、まさにクラウド的な使い方が可能で、豊富に用意されたコンテナを利用して、使い捨てのテスト環境を用意したり、実験的な実装とロールバックを繰り返したり、プロジェクトごとに開発環境を素早く用意したりと、さまざまな用途が考えられる。
現状、時間単位、データ量単位で課金されているコストから解放されるのもメリットで、実際のプロジェクトに乗せる前のアルファ版的なアイデアをローカルで試したり、実装しながら、作りながら新しいアイデアを考えるような使い方に活用できそうだ。
もしかすると、NASが大きなストレージでしかない時代は、これらの技術によって終焉を迎えることになるかもしれない。QNAPとSynology、それぞれルートは違えども、新たなNASの用途を開拓しようとする精神は、大いに称賛したいところだ。