OpenStackとGPU付きインスタンス(Deep Learning)

これは、OpenStack Advent Calendar 2016 4日目のエントリーです。

Deep Learningに代表されるNeural Networkの計算を行う場合、GPUを使えばCPUでの処理と比べた場合に計算時間を10倍程度短縮出来ます。このため学習時にGPUを利用すれば大きな効果を得る事が出来ます。GPUは限られた資源になるため、OpenStackを使ってGPUを皆で共有する環境を構築します。

ホストの準備

OpenStack環境の準備とOpenStackの設定を行います。今回はCentOS 7+Packstackで作成してます。OpenStackをインストールするホストにはnVidiaのGPUを搭載してます。

OpenStackのインストール

Packstackを使ってOpentackをインストールします。詳しくは以下のURLを参考にしてください。

https://www.rdoproject.org/install/quickstart/

SE LinuxはPermissiveにしておきます。

IOMMUの有効化

IOMMUを以下の手順で有効化します。

  1. GRUBの設定
    /etc/sysconfig/grubのGRUB_CMDLINE_LINUXの最後にintel_iommu=onを追記します。例 : GRUB_CMDLINE_LINUX=”crashkernel=auto rd.lvm.lv=rhel00/root rd.lvm.lv=rhel00/swap rhgb quiet intel_iommu=on“
  2. GRUBの書き換え
    GRUBの設定を反映させます。

    # grub2-mkconfig -o /boot/grub2/grub.cfg
  3. サーバーをリブートします。
  4. 設定の反映を確認
    設定が反映されている場合は以下のフォルダが空では無くなります。空の場合は設定に失敗しています。
    /sys/kernel/iommu_groups/

NOVAの設定

NOVAの設定を行い、インスタンスにGPUを添付出来るようにします。

  1. Aliasの設定
    Aliasを指定します。名前はGPUの商品名でも良いですし、自分の好きな名前でも良いと思います。vendor_idは搭載しているGPUのIDを利用します。

    pci_alias = {"name":"GRIDK2", "vendor_id":"10de", "product_id":"11bf"}
  2. スケジューラーの設定
    スケジューラーがインスタンス起動時にPCI Passthroughの状況を確認するようにPciPassthroughFilterを追記します。

    scheduler_default_filters=RetryFilter,AvailabilityZoneFilter,
    RamFilter,Comp uteFilter,ComputeCapabilitiesFilter,
    ImagePropertiesFilter,CoreFilter,PciPassthroughFilter
  3. White Listの設定
    PCI Passthroughで使う機器を設定します。今回はホストに接続されているGPUを指定します。

    pci_passthrough_whitelist = {"name":"GRIDK2", "vendor_id":"10de", "product_id":"11bf"}

OpenStack環境をリブートしてください。

Flavorの設定

Flavorで指定したインスタンスにGPUが添付出来るようにします。以下の設定はFlavor名はg1.mediumとなり、GRIDK2のAlias名が付いたGPUを一つ添付します。最後の数字を2にすると2つGPUが添付されます。

# nova flavor-create g1.medium –is-public true auto 16384 16 4
# nova flavor-key g1.medium set “pci_passthrough:alias”=“GRIDK2:1”

これで準備は整いました。このg1.mediumのFlavorを使ってインスタンスを起動すればGPUが添付された状態になります。

イメージの準備

TensorflowやChainerはnVidiaの提供しているCUDAや、CuDNNを利用してGPUを操作するためにこれらのパッケージをインストールします。私が試した時はCUDA7.5とUbuntu 15.04の組み合わせがベストな組み合わせでした。この組み合わせを見つけるまではかなり苦労をしました。今はCUDA8.0がリリースされていますので16.04が利用出来ると思いますが、組み合わせとして良いのかは試して見るしかありません。

Ubuntuイメージの追加

Horizonの画面か、glance か openstackコマンドを使ってUbuntu 15.04のクラウドイメージを追加します。

イメージの起動

先程の作成したg1.mediumのフレーバーを利用して、Ubuntuのイメージを起動します。

インスタンスへのパッケージのインストール

起動したインスタンスにSSHで接続した後にパッケージをインストールします。

  1. パッケージの追加
    CUDAをインストールするためのパッケージを追加しておきます。

    # sudo apt-get install linux-image-extra-virtual linux-headers-$(uname -r)-
  2. CUDAのインストール
    CUDAをインストールします。CUDAは2G程度あります。

    # sudo dpkg -i cuda-repo-ubuntu1504_7.5-18_amd64.deb 
    # sudo apt-get update
    # sudo apt-get install cuda
  3. CuDNNのインストール
    CUDAのDNN用ライブラリをインストールします。Insallerを付いていないためファイルをDownload後に展開して、ファイルを移動します。

    # tar -zxf cudnn-7.0-linux-x64-v4.0-prod.tgz
    # cd cudnn-7.0-linux-x64-v4.0-prod.tgz 
    # sudo cp lib* /usr/local/cuda/lib64/
    # sudo cp cudnn.h /usr/local/cuda/include/
  4. インスタンスの再起動
  5. GPUの確認
    GPUが添付されているかを確認します。

    # lspci | grep -i nvidia
  6. Tensorflowをインストールします。
    Tensorflowのバイナリをインストールします。今回はテストした時の10.0をインストールします。CUDA7.5とコンパチがあります。最新版の12.0はCUDA8.0対応となってます。

    # export TF_BINARY_URL=https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow-0.10.0rc0-cp27- none-linux_x86_64.whl
    # sudo pip install --upgrade $TF_BINARY_URL
  7. TensorflowでGPUを認識出来ているか確認します。
    以下のコマンドでTensorflowがGPUを認識出来ているか確認可能です。

    # python
     >>> import tensorflow as tf 
     >>> s = tf.Session()
  8. Chainerをインストールする
    Tensorflowの代わりにChainerを使いたい場合は次の手順になります。ChainerはインストーラーがGPUを認識した状態でインストールすると自動的にGPU付きパッケージがインストールされます。

    # sudo pip install chainer

まとめ

OpenStackを使えば、限られたGPUを皆で共有する事が出来ます。また、CUDA付きインスタンスをイメージ化しておけばインスタンスを、作っては壊す事が出来るため今回提示したTensorflow/Chainer以外にもCaffeやmxnet等の様々なDeep Learningのライブラリを試す事が出来ます。

広告
OpenStackとGPU付きインスタンス(Deep Learning)

OpenStackとCalicoでL3 Base NWの実現

OpenStackでは従来より、L2ベースのVXLANの様なオーバーレイを利用したNWが利用されてきました。CalicoはL2ではなく、L3ベースのNWを作成するソフトウェアです。CalicoはやコンテナのオーケストレーションツールやOpenStackと連動して動作する事が前提とされています。

CalicoのNW

CalicoはBGPをベースとしたNWを作成します。BGP自体はLinux上で動作するBIRDというソフトを利用しています。仮想マシンやコンテナは各インスタンス毎に/32のIPアドレスが付与されます。ホストは配下のインスタンスのアドレスをBGPを利用して外部に広報します。ホスト間のルート情報の交換はiBGPでホスト間をフルメッシュで張るか、Route Reflectorを入れる事になります。フルメッシュの設定が大変なためCompute Nodeの台数が多いならRoute Reflectorを入れる事になります。Route ReflectorはProduction環境ではそれなりの物理ルーターを利用する方が良いですが、BIRDでRoute Reflectorを作る手順もCalicoのDocumentに書いてあります。

http://docs.projectcalico.org/en/1.4.2/bird-rr-config.html

OpenStackとCalico

OpenStackとCalicoを連携させると、OpenStackの指示を元にCalicoが各種NW機能を提供します。L3の接続は基本的にLinuxのNW機能を利用します。Security Groupの機能はIPTablesをベースに構成されます。DHCPはdnsmasqで提供します。Calico自身はL3の外部接続機能は提供せずにBGPで経路情報を受け取ったEdgeのルーターで提供する想定となっています。その為必要であればEdgeの物理的/仮想的なルーターでFloating IP等のNAT機能を提供します。今のところIPのOverlapは認められていませんが、想定の実装モデルは議論されているようです。以下に書いてありますが、ホスト内部はIPv4でホスト外部はIPv6を使うモデルを考えているようです。

http://docs.projectcalico.org/en/1.4.2/overlap-ips.html

以下Calicoのお勧めNWモデルが書いてあります。仮想マシン用にPrivate IPとPublic IPをIPv4で作って、Public IPのみをEdge Routerは外部に広報して、管理アクセスはIPv6を利用する形となっています。

http://docs.projectcalico.org/en/1.4.2/opens-external-conn.html

CalicoのOpenStackとの連動

CalicoはOpenStack用のPluginを提供しています。OpenStackから設定情報を受け取ると、Calicoはetcdを使ってノード間で情報を伝達します。また、各種ステータス管理もetcdを利用します。各Compute Nodeではetcdから設定を取り出して、自身を設定するCalicoのClientであるFelixが動作しています。Felixは各Compute NodeでLinuxカーネルのNWの設定、IPtablesの設定、Birdの設定を行います。また、DHCPによるIPアドレスの供給はCalico-dhcp-clientが行い、etcdから設定を取り出してdnsmasqを設定します。

実際のVM起動後にrouteを見ると以下の用になります。以下192.168.10.0/24と192.168.20.0/24と2つのNWがあり、それぞれに1台づつVMが起動している様子です。VMはTap Interfaceにつながっており、192.168.10.2と192.168.20.2で起動しています。

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gateway         0.0.0.0         UG    100    0        0 enp0s3
10.0.2.0        0.0.0.0         255.255.255.0   U     100    0        0 enp0s3
172.24.4.224    0.0.0.0         255.255.255.240 U     0      0        0 br-ex
192.168.10.2    0.0.0.0         255.255.255.255 UH    0      0        0 tapc2930496-e8
192.168.20.2    0.0.0.0         255.255.255.255 UH    0      0        0 tapbb72f1bf-e3

この2つのVMが起動している状態で、インターフェースは以下になります。tapインターフェースが作成されています。GWとDHCPが起動するアドレスとしてns-で始まるインターフェースが設定されています。

# ip a
10: tapbb72f1bf-e3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 500
    link/ether 00:61:fe:ed:ca:fe brd ff:ff:ff:ff:ff:ff
    inet6 fe80::261:feff:feed:cafe/64 scope link 
       valid_lft forever preferred_lft forever
11: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN 
    link/ether aa:8c:df:02:d0:c6 brd ff:ff:ff:ff:ff:ff
12: ns-dd22c5b8-b6: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether 02:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 192.168.20.1/24 brd 192.168.20.255 scope global ns-dd22c5b8-b6
       valid_lft forever preferred_lft forever
    inet6 fe80::ff:fe00:0/64 scope link 
       valid_lft forever preferred_lft forever
13: ns-35f80e94-7f: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether 02:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.1/24 brd 192.168.10.255 scope global ns-35f80e94-7f
       valid_lft forever preferred_lft forever
    inet6 fe80::ff:fe00:0/64 scope link 
       valid_lft forever preferred_lft forever
14: tapc2930496-e8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 500
    link/ether 00:61:fe:ed:ca:fe brd ff:ff:ff:ff:ff:ff
    inet6 fe80::261:feff:feed:cafe/64 scope link 
       valid_lft forever preferred_lft forever

dnsmasqの状態は以下の通りです。

# ps -xa | grep dnsmasq
15895 ?        S      0:00 /sbin/dnsmasq --no-hosts --no-resolv --strict-order --except-interface=lo --pid-file=/var/lib/neutron/dhcp/dd22c5b8-b6ee-4e63-af1d-441a94cda4d7/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/dd22c5b8-b6ee-4e63-af1d-441a94cda4d7/host --addn-hosts=/var/lib/neutron/dhcp/dd22c5b8-b6ee-4e63-af1d-441a94cda4d7/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/dd22c5b8-b6ee-4e63-af1d-441a94cda4d7/opts --dhcp-leasefile=/var/lib/neutron/dhcp/dd22c5b8-b6ee-4e63-af1d-441a94cda4d7/leases --dhcp-match=set:ipxe,175 --bind-dynamic --interface=ns-dd22c5b8-b6 --dhcp-range=set:tag0,192.168.20.0,static,86400s --dhcp-lease-max=256 --conf-file= --domain=openstacklocal --enable-ra --interface=tapbb72f1bf-e3 --bridge-interface=ns-dd22c5b8-b6,tapbb72f1bf-e3
21748 ?        S      0:00 /sbin/dnsmasq --no-hosts --no-resolv --strict-order --except-interface=lo --pid-file=/var/lib/neutron/dhcp/35f80e94-7fac-48b1-a1a8-fe3b4cbd0e99/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/35f80e94-7fac-48b1-a1a8-fe3b4cbd0e99/host --addn-hosts=/var/lib/neutron/dhcp/35f80e94-7fac-48b1-a1a8-fe3b4cbd0e99/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/35f80e94-7fac-48b1-a1a8-fe3b4cbd0e99/opts --dhcp-leasefile=/var/lib/neutron/dhcp/35f80e94-7fac-48b1-a1a8-fe3b4cbd0e99/leases --dhcp-match=set:ipxe,175 --bind-dynamic --interface=ns-35f80e94-7f --dhcp-range=set:tag0,192.168.10.0,static,86400s --dhcp-lease-max=256 --conf-file= --domain=openstacklocal --enable-ra --interface=tapc2930496-e8 --bridge-interface=ns-35f80e94-7f,tapc2930496-e8

 

Calicoのインストール

OpenStackをインストールしておきます。最新版ではLibertyが想定されてます。CentOS上のPackstackで作成した環境にインストールする場合は以下に従ってインストールします。

http://docs.projectcalico.org/en/1.4.2/redhat-opens-install.html

以下注意点です。

  • neutronのDriverの設定はML2を使ってtype_driversとtenant_network_types
    をLocal、mechanism_driversをcalicoで指定します。
  • Calicoのyumのパッケージは署名が正しく無い場合があるので、–nogpgcheckを付けます。
  • birdインストール時にEPELが有効化される必要があるため、/etc/yum.repo.d/epel.repoでepelがenabledになっているか確認します
OpenStackとCalicoでL3 Base NWの実現

OpenStackのGnocchiについて

従来Ceilometerは仮想マシン等のステータス情報をMongo DB等の各種DBを利用していました。このCeilometerの時系列データーを保存する先として従来のDBではスケール上の問題点を抱えていたとの事で、専用のDB ProjectがCeilometer Projectから独立しました。このProjectがGnocchiです。GnocchiはRDOでPackstackを使ってインストールする場合も選択可能となっています。また、RHOSP 9からもRHOSP Directorを利用してのインストールでも利用出来る用になってます。

RHOSP9 Release Note

Gnocchiについて

Gnocchiは時系列データーを保存するデーターベースです。OpenStackが必須ではなく独立してインストールする事も可能です。データーの保存先は、2016年8月時点でFile / Swift / Cephから選択可能です。データーはRESTを使って保存が可能となっています。

Gnocchi Storage Driver

 Gnocchiのインストールについて

GnocchiはRDOで簡単に利用してみることが出来ます。PackstackのAnswer Fileで以下の項目を変更する事で、Ceilometerの情報がGnocchiに保存されます。

CONFIG_GNOCCHI_INSTALL=y
CONFIG_CEILOMETER_METERING_BACKEND=gnocchi

データーの保存について

Gnocchiではインデックスデーターと、時系列データーの保存先を選択出来ます。インデックスデーターはMariaDBやMySQL等に保存します。時系列データーは2016年8月時点では File / Swift / Cephから選択可能です。ファイルの形式は、Gnocchi用に作成されたcarbonara形式となっています。FIleで冗長構成を取る場合はGnocchiが動作しているノード間でNFSで保存先のフォルダの共有が必要になります。ファイルの場合は実データーは/var/lib/gnocchiにファイルとしてデーターが保存されます。実際のデーターは以下の用に保存されます。

# ls -la
total 56
drwxr-xr-x. 17 gnocchi gnocchi 4096 Aug 27 19:21 .
drwxr-xr-x. 56 root root 4096 Aug 27 19:36 ..
drwxr-x---. 10 gnocchi gnocchi 4096 Aug 27 19:21 02fc50b4-95c4-463f-8e5a-c74f142c5931
drwxr-x---. 10 gnocchi gnocchi 4096 Aug 27 19:21 1af707c0-59dd-4eaf-a53a-f4589624818f
drwxr-x---. 10 gnocchi gnocchi 4096 Aug 27 19:21 34c1d5cf-e3c2-41fc-8434-32e8254f7013
drwxr-x---. 10 gnocchi gnocchi 4096 Aug 27 19:21 3d0c4f61-de35-433b-881f-8d5726536c4c
drwxr-x---. 10 gnocchi gnocchi 4096 Aug 27 19:21 3e56d049-e8df-46dd-ba7b-9be24641f057
drwxr-x---. 10 gnocchi gnocchi 4096 Aug 27 19:21 434056ec-2ce8-4257-ac4b-bdfb570f792e
drwxr-x---. 10 gnocchi gnocchi 4096 Aug 27 19:21 613c399e-7267-48f3-8690-f8d06bf4fe97
drwxr-x---. 10 gnocchi gnocchi 4096 Aug 27 19:21 6d472998-5ba0-4b0d-a1cc-8b735eb8c237
drwxr-x---. 10 gnocchi gnocchi 4096 Aug 27 19:21 949b11c5-7385-4d0f-9b37-9070d2694449
drwxr-x---. 10 gnocchi gnocchi 4096 Aug 27 19:21 a14151c5-aa9d-47a4-996a-f7cfa20c5fc9
drwxr-x---. 10 gnocchi gnocchi 4096 Aug 27 19:21 a2ebaaa5-05d6-4825-b88c-dfdf329d4058
drwxr-x---. 10 gnocchi gnocchi 4096 Aug 27 19:21 ce74fcee-efd0-41af-a1ce-8a7c785e6d46
drwxr-xr-x. 2 gnocchi gnocchi 6 Aug 27 19:42 .matplotlib
drwxr-xr-x. 2 gnocchi gnocchi 6 Aug 27 19:21 measure
drwxr-xr-x. 2 gnocchi gnocchi 6 Aug 27 19:21 tmp

大規模環境ではCephへの保存が推奨されています。データーの保存期間や形式はArchiving Policyによって指定されます。Archive PolicyはDefaultではLow / Medium / Highが設定されていますが、自作することも出来ます。Ceilometerの生成するデーターのArchive Policyはceilometer.confで指定する事が出来ます。

コマンドラインでの操作

GnocchiはCLIが用意されてます。GnocchiをKeystoneの認証を連携させている場合は設定ファイルをsourceしてコマンドを実行します。RDOの場合はkeystonerc_adminのファイルをsourceします。gnocchiでは以下のようにコマンドを発行します。

# gnocchi resource list
+------------------------+------------------------+------------------------+------------------------+------------------------+------------------------+----------+-----------------------------+--------------+
| id | type | project_id | user_id | original_resource_id | started_at | ended_at | revision_start | revision_end |
+------------------------+------------------------+------------------------+------------------------+------------------------+------------------------+----------+-----------------------------+--------------+
| 5e3fcbe2-7aab-475d- | generic | None | None | None | 2016-08-26T03:15:03.33 | None | 2016-08-26T03:15:03.335031+ | None |
| b42c-a440aa42e5ad | | | | | 5006+00:00 | | 00:00 | |

+------------------------+------------------------+------------------------+------------------------+------------------------+------------------------+----------+-----------------------------+--------------+

詳しくは以下に記載されています。

http://gnocchi.xyz/gnocchiclient/shell.html

Grafanaでの可視化

Gnocchiに保存されているデーターはGrafanaで可視化出来ます。Grafanaで可視化する場合はGnocchi用のプラグインがリリースされているためそれをインストールして連携を行います。

$ sudo grafana-cli plugins install sileht-gnocchi-datasource

プラグインをインストールするとGrafana上のデーターソースにGnocchiが出てきます。データーソースとしてGnocchi IPを指定するか、Keystone経由でGnocchiを見つける事が出来ます。データーはブラウザから直接Gnocchiに接続して取得するdirectか、一度Grafanaサーバーで受けるかのproxy指定が出来ます。proxyの時はGrafanaの制約で複数のサーバーに問い合わせが出来ないとの事でKeystoneが利用出来ません。

screencapture-10-44-58-140-3000-datasources-new-1472448833970

DataソースとしてGnocchiを指定してQueryを発行すると、取得したデーターからグラフの作成が出来ます。以下は特定のホストに載っている仮想マシンのCPU使用率を表示しています。

screencapture-10-44-58-140-3000-dashboard-db-new-dashboard-1472535027549

まとめ

Gnocchiは、Projectが発足して時間が経っていないので、まだまだ採用されないと思っていました。RedHatが積極的に採用していく流れのようなので、今後とも注目していきたいと思っています。

OpenStackのGnocchiについて

OpenStack上のNWトラフィックをKibanaで可視化する

Logの可視化として、FuluentdとElasticsearch/Kibanaの組み合わせが使われています。今回のこの組み合わせで、OpenStackのOVS上に流れるトラフィックを可視化します。NWトラフィックを可視化する場合にOpenStack環境の物理スイッチ側でトラフィックを取ることも出来ますが、仮想マシン間の通信がホスト内で完結されてしまうと、その部分のトラフィックの様子を見る事が出来ません。OpenStackの構造上、各ホスト上のbr-int上を流れるトラフィックを可視化出来れば仮想マシン間も含めたすべての通信を見ることが出来ると考えられます。

Netflow / sFlowについて

NetflowはCisco機器が備えているNW可視化の仕組みです。ポートミラーリングはトラフィクをコピーする仕組みですが、NetflowはIPアドレスやポート番号等の情報を抜き出して、指定のホストに対して情報を送信する仕組みです。sFlowはNetflowを一般化したものになります。Fluentd用にNetflowプラグインが開発されていますので、Netflowで出力すれば簡単にElasticsearch側にデーターを出力出来ます。しかしながらOVSはNetflowでの出力も備えていますが、サンプリングレートや出力先のインターフェースの指定を備えていないようです。今回br-intのトラフィックを取るためにインターフェース自体にIPは振られていないため、出力先インターフェースの指定が必要です。そのため今回はOVSからはsFlowで出力して、それをNetFlowに再変換してElasticsearchに入力します。

OVSの設定を行う

OVS上でのsFlowの設定方法は以下に詳しく述べられています。

http://openvswitch.org/support/config-cookbooks/sflow/

OpenStackのコンピュートノードや、コントローラーノード上で以下の設定を行いbr-int上に流れるトラフィックのsFlowのデーターを送付します。送信先はsFlow Toolが動作するホストになります。sFlow Toolが動作するホストは10.0.0.1の想定で設定しています。

ovs-vsctl — –id=@sflow create sflow agent=eth1 target=”10.0.0.1:6343″ header=128 sampling=64 polling=60 — set bridge br-int sflow=@sflow

sFlow Toolを使う

sFlow ToolはsFlowを可視化してくれたり、NetFlowへの変換行ってくれるツールです。基本的に以下のレポジトリからCloneして、makeすればバイナリを生成して利用出来ます。

https://github.com/sflow/sflowtool

以下のコマンドで起動しておけばsFlow ToolがsFlowのデーター受け取った後に、Netflowに変換して送信してくれます。以下はLocalのFluentdに送信する想定です。

sflowtool -p 6343 -c 127.0.0.1 -d 5140

FluentdのNetflow Pluginを使う

Fluentd用のNetflow Pluginは以下で開発されています。

https://github.com/repeatedly/fluent-plugin-netflow

FluentdのコマンドでこのNetflow Pluginをインストールします。

td-agent-gem install fluent-plugin-netflow

インストール後にFluentdのtd-agent.confで以下の設定を行えば変換されたNetflowのトラフィックを受け取る事が出来ます。受け取ったNetflowのトラフィックにはgeo.netflowのタグ付けをして次の処理を行います。

<source>
  type netflow
  tag geo.netflow
  port 5140
  versions [5]
</source>

IPアドレス情報からGeoLocationを生成する

sFlowで収集した情報にSourceやDestのIPアドレスを元に、GeoLocatoinのタグを付与してあげれば、Kibana上で通信の場所をプロット出来ます。今回はFluentdのIPアドレスからGeoLocationタグを生成出来る以下のプラグインを利用します。

https://github.com/y-ken/fluent-plugin-geoip

以下のコマンドでインストールします。Developer Tool等のインストールも必要になります。

# sudo yum group install "Development Tools"
# sudo yum install geoip-devel --enablerepo=epel
# td-agent-gem install fluent-plugin-geoip

以下の設定をtd-agent.confに追加するとGeo Locationへの変換を行ってくれます。今回の設定ではDestination IPを元にGeoタグを付与しています。

<match geo.netflow>
  type geoip
  geoip_lookup_key ipv4_dst_addr
  <record>
    geoip_pin ${latitude["ipv4_dst_addr"]},${longitude["ipv4_dst_addr"]}
  </record>
  remove_tag_prefix geo.
  tag es.${tag}
  skip_adding_null_record
</match>

Elasticsearchにデーターを送る

データーを送信し始める前にElasticsearch側が必要なデーターをGeo Tagとして認識出来るようにテンプレートを定義しておきます。

curl -XPUT localhost:9200/_template/flow -d '
{
  "template" : "flow-*",
  "mappings" : {
    "netflow" : {
      "properties" : {
        "@timestamp" : {
          "type" : "date",
          "format" : "dateOptionalTime"
        },
        "ipv4_src_addr" : {
          "type" : "string"
    },
        "geoip_pin" : {
          "type" : "geo_point"
        }
      }
   }
  }
}'

FluentdのElasticsearchプラグインをインストールします。

# td-agent-gem install fluent-plugin-elasticsearch

FluentdのElasticsearchプラグインでデーターを送付します。td-agnt.confの設定は以下の通りです。以下の例ではLocalのElasticsearchにデーターを送信しています。

<match es.netflow>
  type elasticsearch
  host 127.0.0.1
  port 9200
  type_name netflow
  logstash_format true
  logstash_prefix flow
</match>

Kibanaで可視化する

Elasticsearchで集めたデーターはKibanaを使って、以下のように可視化出来ます。

図1

まとめ

実運用で使うなら、sFlow toolを挟まずにFluentdかLog StashのsFlowプラグインを開発した方が良い気がします。

OpenStack上のNWトラフィックをKibanaで可視化する

Hyper-V上へのOpenStackインストール

OpenStackのPOC環境でOpenStackの動作を確認する場合に、物理マシンを使うのが正解ですが再インストールを繰り返すなら仮想化環境上の仮想マシンにインストールすると色々便利です。仮想化環境はKVMやVMwareを利用しても良いですが、今回はHyper-Vを利用してみます。KVMやVMwareはよく利用されますがHyper-Vはあまり経験が無かったので共有します。

仮想マシンの作成とインストール

今回は、OpenStackの外部接続用とマネジメント+Data用の2つのNWを用意します。仮想スイッチは外部で作成するため、Hyper-Vのホストに2つのNICを用意しておきます。まずは仮想マシンをマネジメント+Data用のNWに接続して起動します。仮想マシンは第1世代で作りました。またメモリはOpenStackを動作させるなら最低でも4G以上の設定をしておきます。今回はRDOでPackstackを使ってインストールするのでCentOS7.1のISOをマウントして、仮想マシンへのインストールを行います。2台目を用意して、複数のComputeを試してみたい場合は同様の設定の仮想マシンをもう一台用意します。 “Hyper-V上へのOpenStackインストール” の続きを読む

Hyper-V上へのOpenStackインストール

DatadogでOpenStackをモニターする

DatadogモニタリングをSaaSで提供しているサービスですが、OpenStackと接続出来るIntegrationが提供されています。今回はOpenStack Integrationを利用して、DatadogからOpenStackをモニターします。

Datadogについて

DatadogはSaaSベースで提供されていますモニタリングサービスです。各種アプリケーションや、サービスに対応したIntegrationが提供されており簡単にメトリックの追加を行うことが出来ます。PythonベースでIntegrationを自作する事も出来ます。

Datadogの利用開始

Datadogは以下サイトでサインアップをすると無料枠で利用出来ます。

https://www.datadoghq.com/

サインアップ後の画面を進めると、Datadog Agentのインストール画面が出てきます。利用するOSを選択して、Datadog Agentのインストール方法を確認します。CentOSであれば、ワンライナーでインストールからDatadog Agentの起動が行われます。このスクリプトはYumレポジトリの登録と、Datadog Agentのインストール後にDatadog Agentの設定を行ってくれます。Agentをインストールすると自動的にDatadogのサービスに対してデーターが送信されます。AgentのステータスはCent OSであれば以下のコマンドで確認が可能です。内部的には複数のサービスが動作しているため、こののコマンドでの正常動作の確認は必須です。

service datadog-agent info

“DatadogでOpenStackをモニターする” の続きを読む

DatadogでOpenStackをモニターする

OpenStack IronicでVirtualBoxを操作する

Ironicは物理マシンと接続して、電源管理等を行うために様々な機器に対応したドライバーが提供されています。その中で、検証等に使えるVirtual Box用のドライバーも提供されています。Vitual boxが操作出来るドライバーはSSHを使ってコマンドを発行するSSHドライバーとVirtual BoxのSOAP APIに接続する2種類提供されています。

SSHドライバーについて

SSHドライバーはVirtual Boxを含む仮想化環境に対応しています。virtual box / virsh / vmware / parallels / xenserverと多種多様な仮想化環境に対応しています。SSHドライバーは仮想化基盤にSSHで入ってコマンドを発行して操作するためにSSHのホスト側の機能が必要です。例えばVirtual BoxであればVBoxManageコマンド、VMware(ESXi)であればvim-cmdコマンド、virshであればvirshコマンドで操作を行います。

https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/ssh.py

Virtual Boxドライバー

SSHのサーバーを立てれない場合の為に、Virtual Boxが提供しているWeb Serviceを使うドライバーも提供されています。これはKiloで提供されました。これを使えばMACやWindowsでVirtual Boxを動作させて手軽にIronicの試験が出来るようになります。今回はRDOのLiberty版を利用して、両方のドライバーの使い方を解説します。

http://docs.openstack.org/developer/ironic/drivers/vbox.html

“OpenStack IronicでVirtualBoxを操作する” の続きを読む

OpenStack IronicでVirtualBoxを操作する