読者です 読者をやめる 読者になる 読者になる

仮想化通信

日本仮想化技術株式会社の公式エンジニアブログ

MAASを稼働させている環境でシステムアップデートをする場合の注意

MAAS

Canonical MAASの1.8がリリースされました。ChangeLogを見ればわかるように、前バージョンの1.7と比べ、数々の修正が行われています(設定も含む)。

使い勝手などはおってここで取り上げたいと思いますが、MAASのPPAを追加してあたらしいバージョンのMAASを使っている場合、システムアップデートに注意する必要があります。

普段、sudo apt-get upgradeでシステムの更新をしている場合は現時点ではMAAS 1.7から1.8に更新されることはないのですが、apt upgradeコマンド(apt-get dist-upgrade相当)を使ったり、apt-get dist-upgradeを行ったりするとMAAS 1.8に更新されてしまい、MAAS 1.8向けの設定に書き換えないと503エラーが表示され、利用できなくなるので注意が必要です。

MAASをご利用の方はご注意ください。

maas18

(図 apt-get upgradeコマンドでは前のバージョンがキープされるが...)

UpdateFailed

(図 dist-upgradeを強行突破すると正常動作しなくなります)

CentOS 6.6で簡単に使えるUSB接続無線LANアダプタ

うちで使っている研修用ノートPCには、コストをケチったおかげで無線LANがついていません。

よく、トレーニングの受講者さんとか、ちょっと検証するときに有線LAN接続が面倒だな〜、と思っていて、USB接続の無線LANアダプタをつけようと思っていたのだけど、Linuxでも、CentOS 6あたりでも使えるのがいいよね、ということで検証してみました。正確には検証しないといけないんだけど、サボっていたのに、お尻に火が付いて大急ぎで試してみました。

結論から言うと、バッファローWLI-UC-GNMが挿すだけで認識されて、かつAmazonで700円と安いので、10個まとめ買いしました。

挿してlsusbコマンドで確認すると、こんな風に見えます。

Bus 002 Device 005: ID 0411:01a2 BUFFALO INC. (formerly MelCo., Inc.) WLI-UC-GNM Wireless LAN Adapter [Ralink RT8070]

iwconfigで確認するときちんと見えていて、ネットワーク設定アプリで普通に設定できました。NetworkManagerなら尚簡単。

多分、Windowsでも普通に動くんじゃ無いかな。

 

MacにVagrant環境を作る

サーバー

MacにVagrantの環境を作ったらなかなか便利だったので、再度環境を構築する時のためにここに書き留めておきたいと思います。

まずは必要なものをダウンロードして、インストールします。

VagrantはVirtualBox以外もサポートしますが、無償で使える組み合わせは上記の組み合わせなんだそうです。インストール後はターミナルなど(私はiTermの方が好きです)を起動し、コマンドを実行してみます。

$ vagrant version
Installed Version: 1.7.2
Latest Version: 1.7.2

You're running an up-to-date version of Vagrant!

次に作業ディレクトリーを作ります。ディレクトリー名は適当です。

$ mkdir -p ~/vagrant/projects/

Boxをシステムに登録します。Boxとは簡単に言うとインストール済みOSイメージの事です。

Ubuntu 12.04.x

$ vagrant box add precise https://cloud-images.ubuntu.com/vagrant/precise/current/precise-server-cloudimg-amd64-vagrant-disk1.box

Ubuntu 14.04.x

$ vagrant box add trusty https://cloud-images.ubuntu.com/vagrant/trusty/current/trusty-server-cloudimg-amd64-vagrant-disk1.box

※改行をいれず、一行で入力してください。

Fedora 22

$ vagrant box add Fedora http://download.fedoraproject.org/pub/fedora/linux/releases/22/Cloud/x86_64/Images/Fedora-Cloud-Base-Vagrant-22-20150521.x86_64.vagrant-virtualbox.box

※改行をいれず、一行で入力してください。

CentOS 6.6

$ wget https://atlas.hashicorp.com/ytooyama/boxes/centos66-minimal/versions/6.6.20150602/providers/virtualbox.box
$ vagrant box add CentOS virtualbox.box

※改行をいれず、一行で入力してください。ダウンロードが中断された場合はwgetコマンドに-cオプションをつけてレジュームしてください。

非公式なものも含まれていますが、vagrant boxのイメージがこちらに掲載されています。 http://www.vagrantbox.es

~/vagrant/projects/のディレクトリー配下に、起動するOS用のディレクトリーを作り、設定ファイルを作成します。

Ubuntu 12.04なら

$ mkdir -p ~/vagrant/projects/precise/
$ cd ~/vagrant/projects/precise/
$ vagrant init precise

Ubuntu 14.04なら

$ mkdir -p ~/vagrant/projects/trusty/
$ cd ~/vagrant/projects/trusty/
$ vagrant init trusty

起動に関する設定がVagrantfileに書かれているので適宜編集。

# Every Vagrant development environment requires a box. You can search for
# boxes at https://atlas.hashicorp.com/search.

config.vm.box = "trusty"

# VM Hostname
config.vm.hostname = "trusty"  (ホスト名を設定する場合追記)

# Create a public network, which generally matched to bridged network.
# Bridged networks make the machine appear as another physical device on
# your network.
# config.vm.network "public_network"
config.vm.network "public_network", bridge: "'en0: Ethernet" (ブリッジ接続を追加する場合追記)

用意したコンフィグレーションで起動

$ cd ~/vagrant/projects/trusty/
$ vagrant up

インスタンスにSSHログイン

$ cd ~/vagrant/projects/trusty/
$ vagrant ssh

インスタンスをサスペンド

$ cd ~/vagrant/projects/trusty/
$ vagrant suspend

インスタンスを停止

$ cd ~/vagrant/projects/trusty/
$ vagrant halt

削除

$ cd ~/vagrant/projects/trusty/
$ vagrant destroy

2015-06-01 04:13:26 +00001

Vagrantの導入と簡単な使い方は以上です。筆者は雑誌の原稿を作る際にLinux環境を使うので、Vagrantを使える環境を作った事で原稿がはかどりそうです。あとは原稿を書けば...

[7/8/2015 追記]

内容を追加、修正しました。

Dockerのストレージ検証

Docker

Dockerコンテナーのデフォルトのストレージは遅いという話をよく聞くので、実際にどれくらい差があるのか調査してみました。Fedora 21でDocker 1.6環境を構築してコンテナーを起動し、コンテナー内でdbenchを実行しました。5/26にFedora 22がリリースされましたが、検証環境の構築をしたのがリリース前だったためFedora 21を使った場合の検証結果です。

Fedora 21はLVM,BTRFS,LVM Thin Provisioning(以下LVM-Thin)モードでパーティションを作り、Dockerコンテナーを起動時に-vでそのディスク上に作ったディレクトリーをマウントしました。

2015-05-28 01:30:42 +00001

実行したコマンドは次の通りです。-vオプションでDockerホスト上の/opt/volumeをコンテナーの/opt/volumeとしてマウントしています。dbenchの作業データを-Dオプションで/opt/volumeに置くように設定しています。

# docker run --net=host --name=first -v /opt/volume:/opt/volume -it docker.io/fedora:latest /bin/bash
# yum install -y dbench && dbench -D /opt/volume 5

Dockerホストでのベンチマーク結果

まずはストレージパーティションの種類ごとの性能を比較するため、Dockerホストでベンチマークをとってみました。次がその結果です。

LVM
Throughput 52.5299 MB/sec
BTRFS
Throughput 37.9817 MB/sec
LVM-Thin
Throughput 52.3901 MB/sec

LVMとLVM-Thinは性能が変わらないようです。それと比べるとちょっとBTRFSはスループット値が低いです。

Dockerデフォルト(UnionFS)の性能

次はDockerで特になにも意識せずにコンテナーを起動した時のベンチマーク結果の比較です。

LVM
Throughput 9.4759 MB/sec
BTRFS
Throughput 32.3827 MB/sec
LVM-Thin
Throughput 8.09645 MB/sec

LVMは遅くなったのに対し、BTRFSは性能があまり変わらないという面白い結果が出ました。

-vでボリュームマウントした場合

最後にディスクをマウントした場合の結果です。-vについてはこちら

LVM
Throughput 50.6346 MB/sec
BTRFS
Throughput 37.5545 MB/sec
LVM-Thin
Throughput 47.9169 MB/sec

LVMについては-vでマウントしたディスクの読み書きはネイティブの読み書きとほぼ変わらないという結果になりました。BTRFSは-v指定しない場合と比べると、ネイティブと変わらない性能が出ているのがわかりました。

というわけで、Dockerにおける-vオプションの優位性が確認できました。ストレージ読み書きの性能が重要視されるサービスを動かす場合は-vは必須と言えそうです。

vSphere ESXi 6.0へのアップグレードについて

VMware

前回はvSphere 6の変更点について取り上げました。今回は旧バージョンからのアップグレードについて書きたいと思います。

VMware ESXi(以降ESXi) 5.xからESXi 6.0へのアップグレードについては、公式マニュアルの「vSphere のアップグレード」ガイドにあるようにUpdate Managerを使う方法もありますが、ESXi 6.0のISOイメージを使ってアップグレードインストールするのが簡単です。こちらの手順で説明されている方法でバックアップを取った上でアップグレードを実施します。

【実行例】

PowerCLI> Connect-VIServer 172.17.14.10 -User user -Password pass
(接続)
PowerCLI> Get-VMHostFirmware -DestinationPath C:\backup
(指定パスにバックアップ)

シングルアップグレードをサポートする対象のESXiバージョンはVMware Product Interoperability Matrixesにあるように、ESXi 5.0以降のバージョンであればサポートしています。アップグレード時に使うESXi 6.0のISOイメージはそのメーカー向けにカスタマイズされているISOイメージを使って行います。

ESXi 4.xからESXi 6.0へのシングルアップグレードはサポートされておらず、弊社で確認したところ、次のような流れでアップグレード可能であることがわかりました。

  1. ESXiホストをメンテナンスモードに移行
  2. ESXi 4.xからESXi 5.5U2へのアップグレード
  3. データストアをVMFS3からVMFS5へアップグレード
  4. ESXi 5.5U2からESXi 6.0へのアップグレード
  5. ESXiホストのメンテナンスモードを解除

vCenter Server 6は5.0以降のバージョンのESXiをサポートしているので、ESXi 5.5U2にアップグレードした後vCenter Serverに追加してVMをvMotionし、クリーンインストールしてしまうのもいいと思います。

最後に仮想マシンのバージョンですが、ESXi 6.0ではバージョン4以降の仮想マシンをサポートします。しかし最新のバージョン11にすると割り当てられるハードウェアリソースを多く割り当てられるというメリットがあります。ESXiをシングルで利用している場合はvSphere Clientで選択できるOSの種類が増えるというメリットもあります。ESXi 6.0でサポートしていないOSを動かすわけでもない限り、仮想マシンのバージョンもアップグレードすべきだと思います。

vsphere6-connect

HP Moonshot 1500でDockerコンテナーをたくさん動かしてみた

Docker サーバー

先日、Dockerの検証機材としてHP Moonshot 1500とProLiant m300 Server Cartridge、ProLiant m710 Server Cartridgeをお借りしてDockerとKVMの性能比較などいろいろ行いました。

お借りする期間を延長していただけたので、もう少し触ってみることにしました。

DockerコンテナーをHPサーバーで利用しているユーザーの多くは、一台のサーバーあたりおおよそ1000のコンテナーを動かすのが一般的なんだそうです。そこで実際ProLiant m300 Server Cartridge(以降m300)でDockerを動かし、どれくらいまでコンテナーを動かせるかを検証してみました。ちなみにDockerホストのOSはメインの検証で使ったRed Hat Enterprise Linux Server release 7.0 (Maipo)と、最近バージョンが更新されたDocker 1.6の組み合わせで行っています。

調査中、1023個まではコンテナーが作れるのにもかかわらず、1024個目を作ろうとするとエラーになるのが気になっていました。性能の限界かと思ったのですが、CPUもメモリーもストレージも上限に当たっている様子はありません。調べたところ、次のような情報を見つけました。

重要な部分を引用します。

a single Linux bridge can only handle 1024 ports. This limits the scalability of docker as it won’t be possible to create more than 1024 containers

なるほど。

そこで、Dockerのネットワークについて、公式のマニュアルを調べて、ネットワークモードの動作の違いについて調査してみました。

# brctl show

bridge name bridge id STP enabled interfaces
docker0 8000.56847afe9799 no
(コンテナーが1個もない状態)

# docker run -d --name=test1 --net=host -it registry.access.redhat.com/rhel7.0:latest /bin/bash
7889a809926128f48d4c0cae6914e...
(--net=hostモードでコンテナを起動)

# brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.56847afe9799 no
(--net=hostではブリッジインターフェイスは増えない)

# docker run -d --name=test2 --net=bridge -it registry.access.redhat.com/rhel7.0:latest /bin/bash
95f8740099736c2002f41c174140841e...
(--net=bridgeモードでコンテナを起動)

# brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.56847afe9799 no veth976a950
(--net=bridgeではブリッジインターフェイスは増加)

このことから、--net=hostモードであればコンテナ1024個の制限を越えられるのではと思いました。結果、コマンドを実行し、--net=hostモードで1024コンテナーを起動することができました。

では次に2000個動かしてみます。一般的に利用される倍の数です。m300はAtom CPU機なのにもかかわらず、もちろんサクッと2000コンテナも動きました。さすがですね。

docker2000-1

ちなみにDockerコンテナーは次のようなシェルスクリプトでちびちびと作りました。

#!/bin/bash
for i in {1..100}
do
docker run -d --net=host -it myrhel7:latest /bin/bash && \
echo $i
done
echo ":) Finished"
docker ps -aq|wc -l
echo "個作成完了"

docker psコマンドはコンテナー一覧を表示するためのコマンドです。aオプションで起動中のコンテナを表示、qオプションでコンテナーIDのみ出力し、その結果をwcコマンドでカウントしています。

次の図は2000コンテナー作ったあとのストレージの使用状況とシステム負荷を確認したスクリーンショットです。コンテナーを増やすたびにdfコマンドの結果を確認していきました。コンテナ数に比例してUsedが増えていきましたが、2000コンテナー動かしてもDockerホストを含めて4GBしか使われていないので、まだまだ詰め込むことができそうです。

ロードアベレージについてはコンテナーの作成中は多少負荷が上がりますが、コンテナーが起動後は1以下まで落ちました。コンテナーあたりの負荷をよく計算した上で環境を構築すれば、Dockerは充分実用的であると言えそうです。

docker2000-2

このことから、1024個以上コンテナを動かしたいときは

  • デフォルトの--net=bridgeモードは不向き
  • --net=bridgeモードを使いたいときはOVSを使うと良い
  • ポートかぶりに気をつける必要があるが--net=hostモードなら動く

ということがわかりました。

Red Hat Enterprise Linux 7とHP ProLiant m300 Server CartridgeならDocker環境も快適に動作します。皆さんも是非、Docker構築にチャレンジしてみてください。

RDO PackstackでOpenStack Kiloの構築

KVM OpenStack

RDO PackstackでOpenStack Kiloの構築をしてみました。

RDO PackstackはRHELCentOSFedoraなどでOpenStack環境をデプロイできるデプロイツールのひとつです。これを使って、Havanaの頃から代々検証環境をデプロイしていますが、なかなか便利なツールで私は気に入っています。

普段テスト環境を作る時はパッケージバージョンの古さとかでハマるのが嫌なので、比較的に新しいバージョンのFedoraを使って構築するのですが、MLの書き込みによると現時点(5/20/2015)でパッケージの準備が出来ていないようなので、今回はCentOS 7で構築してみることにしました。

いつものようにRDOが提供するリポジトリーを追加、answerファイルを作り設定を書き換えてデプロイ。単体構成もマルチノードもこれまでと比べると結構簡単にできました。Packstackさすが!...ところが...。

構築した環境について

次のようなOVSを使った3台構成を想定しました。

  • コントローラーノード
  • ネットワークノード
  • コンピュートノード

構築手順は以下にまとめた通り行いました。

ちなみに、1台のマシンに全部のせする手順は以下にまとめています。

Kiloを使ってみて

今回、前のバージョンと同じスペックの環境上に構築したのですが、Junoと比べて全体的な負荷が高いように感じました(特にKeystoneとHorizon関連のプロセスが重い)。

1台の環境に全部のせしたのが良くないのかと思い、3台のマシンにそれぞれサービスを分散して3台構成のKilo環境を作ってみたのですが、インスタンスを起動したり削除したりするとロードアベレージが7を超えることが度々あり、Kiloを利用するには動作させるスペック、例えばCPUのコア、実装するメモリー、ストレージサイズやストレージの読み書き速度などについて十分に検討する必要があるように感じました。

2015-05-20 08:54:00 +00001

(図 負荷が高くなって"どこかおかしくなった"RDO版Kilo ... ブラウザの更新ボタンを押すと正常に戻ったり戻らなかったりします)

また同上の画面になり、Dashboardからログインできなくなるといった問題も度々起きました。これはログインできなくなったDashboardCookieブラウザーから削除したら解消しました。なんらかの理由により、Cookie内の情報が壊れてしまうのかもしれません。

2015-05-20 10:06:22 +00001

(図 ログインできない問題はCookie削除でたいてい解消する模様)

とはいえ、まだリリースされてから一ヶ月しか経過していませんし、ディストリビューションが配布するKiloのパッケージも公開されてから一週間も経っていません。とりあえず様子を見たいと思います。

なにか解決策があればこちらなどで報告したいと思います。