IDCF Tech-Blog

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

IDCF Tech-Blog

クラウド・ビッグデータ・データセンターを提供するIDCフロンティアの公式エンジニアブログ

コミュニティテンプレート Vuls の利用とTips

こんにちは。株式会社アールワークスの井上と申します。

VulsユーザーズグループであるVulsのSlackに参加している関係で、記事を書く機会をいただきました。 IDCFクラウド アンバサダープログラムのMORIO Dojoにも参加しています(白帯のままです...)。

前回は、Vulsのミートアップである Vuls祭りVol.1の記事を書きました。引き続き、Vulsの記事を寄稿させていただきます。

さて先日、IDCFエバンジェリストグループの方から、Vulsのコミュニティテンプレートが公開されました。 今回は、このコミュニティテンプレートについて内容を確認し、追加の情報を提供させていただきます。

  • 始まりのVuls/VulsRepo (Vulsを使ってみよう)
  • Vulsコミュニティテンプレート利用時に役立つTips
  • Vulsコミュニティテンプレートの構成について
  • Vulsミートアップ「Vuls祭り #2」のご紹介 & 有用なリンク集
  • 最後に

まずは、Vulsアップデートはせず、テンプレートのまま使ってみましょう。

始まりのVuls/VulsRepo

そもそも、Vuls/VulsRepoとは

f:id:kkamiyakenshiroh:20170313103504p:plain
Vulsは、OSSの脆弱性検知ツールです。Githubで公開されています。

  • コミュニティはSlackにあります。自由に参加可能です
  • 英語圏での反響もあるため、GithubのPullRequestやIssueは英語のことが多いです
    • ですが、Slack内のvulsjpでは日本語でやり取りされているので、英語が苦手でも大丈夫です

VulsRepoは、Vulsのスキャン結果をインタラクティブに見ることができる、OSSのWEBアプリケーションです。 こちらもGithubで公開されています。

  • 使い方は、Github上にgif動画で公開されています
  • 基本的には、見たいスキャン日時やサーバーを選択し、任意の条件でドリルダウンしていくように使います

Vulsでスキャンして、VulsRepoで見る、というのが一連の流れになります。

使ってみよう

Vulsコミュニティテンプレートを利用することで、Vuls/VulsRepoをすぐに利用できます。 初期設定では、自分自身の脆弱性をスキャンするように設定されています。

  1. Vulsコミュニティテンプレートから、サーバーを作成
  2. 構築したサーバーへのアクセス経路を調整
  3. SSH接続し、脆弱性のスキャン
  4. HTTPアクセスで、脆弱性の状況を確認

簡単ですね。
もう少し詳しく、設定を見てみましょう。

1.Vulsコミュニティテンプレートから、サーバーを作成
サーバーの作成方法は、他のコミュニティテンプレートの作成方法と同じですので、割愛します。
IDCFが「コミュニティテンプレートから仮想マシンを作成する」というTIPSページを公開しています。
https://www.idcf.jp/help/cloud/guide/vm_community_temp.htmlwww.idcf.jp

2.構築したサーバーへのアクセス経路を調整
サーバー作成後、Vuls設定のためにSSHアクセス、VulsRepoを見るためにHTTPアクセスの設定が必要になります。

  • IDCFクラウド上のサーバーで同じセグメントから利用する分には、特に設定は不要です
  • インターネット側から見る場合には、ポートフォワードとファイアウォールの設定が必要になります
    • インターネット経由でアクセスをさせる場合は、アクセス制限等を 別途しっかり行う必要があります。 必要に応じて、ソースIP制限や認証の追加をしましょう
    • 今回は特に制限を行わず、作成したサーバーをインターネット経由で公開してテストしました
ポート番号 用途
22 Vulsの設定時に必要
80 VulsRepoの閲覧時に必要

3.SSH接続し、脆弱性のスキャン
設定が出来たら、SSHで作成したサーバーにログインし、脆弱性スキャンをしてみましょう。

  • サーバー作成直後であれば、rootでのみログインできます
  • su で vulsユーザになり、スキャンコマンドを実行します
    • go-cve-dictionaryというCVEデータベースのアップデートを行ったあと、vulsでスキャンを行います

f:id:kkamiyakenshiroh:20170313103356p:plain

今回は、CVE番号が割り当てられている脆弱性はなく、12個分の更新がある事が分かります。

  • 12 updateable packageとありますが、1つにパッケージに複数の更新がある場合もあるので、yum upadteで出てくる アップデート可能パッケージ数とは異なる場合があります
    • この記事のタイミングで上記確認できたので、最新版では修正されます。 Vulsのupdatableの数は、check-updateの数と同じになります

次に、Vulsスキャン結果を CVEデータベースと突き合わせる report コマンドを発行します。

  • reportコマンドにより、パッケージのChangelogにある CVE番号から、共通脆弱性評価システムCVSSの情報と連携します
    • CVSSについては、IPAの資料が詳しいです
    • ざっくりと、どの程度危険なのかを判別するための情報、と考えてよいです
    • 見方がよく分からない場合は、Base値 ( 基本値 ) を見て、大きいほうが影響が大きい、と考えてください
  • レポート形式は複数選択可能です
    • 出力先は -to オプションで選択します。ファイルの場合は -to-localfile、Slackの場合は -to-slackなどです
    • 出力フォーマットは -format オプションで選択します。XMLの場合は -format-xml、短いテキストの場合は -format-short-textなどです
  • VulsRepoはjson形式が必要となるため、-to-localfile -format-json で出力する必要があります
[vuls@vuls vuls]$ vuls report -to-localfile -format-json
[Mar  6 20:38:50]  INFO [localhost] Validating Config...
[Mar  6 20:38:50]  INFO [localhost] cve-dictionary: /opt/vuls/cve.sqlite3
[vuls@vuls vuls]$ vuls report -format-full-text
[Mar  6 20:39:00]  INFO [localhost] Validating Config...
[Mar  6 20:39:00]  INFO [localhost] cve-dictionary: /opt/vuls/cve.sqlite3

vuls-server (centos6.8)
=======================
Total: 0 (High:0 Medium:0 Low:0 ?:0)    12 updatable packages

No CVE-IDs are found in updatable packages.
12 updatable packages

[vuls@vuls vuls]$

4.HTTPアクセスで、脆弱性の状況を確認
スキャンとレポーティングが無事に完了したので、VulsRepoで見てみましょう。 今回はCVE番号が割り当てられた脆弱性はないため、healthy、という表示になっています。

  • http://割り当てたIP/vulsrepo/ へアクセスすると表示されます
  • 最初に、左側から「確認したい日付」を選びます
    • 複数選択可能です。チェックを入れて「submit」を押してください
  • 左側の項目を ScanTime の列に移動させることで、項目ごとでのドリルダウンが可能です

f:id:kkamiyakenshiroh:20170313103555p:plain
これで、一連の スキャン/閲覧(と対応)の流れが終わりました。

次のステップ

まずは使ってみる、という観点からそのまま動かしてみました。しかしながら、これだけでは今回構築した Vulsサーバーしか脆弱性検査ができません。
次回以降、ほかのサーバーをスキャンする方法などを記載していきます。

Vulsコミュニティテンプレート利用時に役立つTips

Vulsは開発速度が速く、日によっては毎日PullRequestやMargeがされています。これは、脆弱性検知精度向上や 新たな対応OSの追加などのためです。( 先日、RaspberryPi用のRasbianがサポートOSに加わりました! )

自分でVuls/VulsRepoを更新することで、追加された機能/バグ修正/検知精度向上の効果を得ることができます。 アップデート手順等は次回以降で記載します。
今回は、コミュニティテンプレート版でも使える、最近実装した機能を紹介します。

ローカルスキャンを使う

同梱されている設定は、自分自身へ SSH経由でのスキャン を実施する設定です。 しかしながら、なるべくSSHでのスキャンをしたくない環境もあります。

その際に有用なのが、Vulsのローカルスキャンモードです。

  • ローカルスキャンの詳細については、次回以降で説明します
  • SSH接続をしてスキャンをするのではなく、ローカルのコマンドを利用してスキャンを行います
    • スキャンユーザには、SSH接続でのスキャン ( リモートスキャン ) と同様の権限が必要です

ローカルスキャンの設定

設定は、config.tomlを以下のように書き換えるだけです。

  • portをlocalに変更し、SSHユーザ/鍵の記載を削除する
    • hostが"localhost"若しくは"127.0.0.1" かつ portが"local"、の場合にローカルスキャンモードとなります
[servers]

[servers.vuls-server]
host         = "127.0.0.1"
port        = "local"

設定後、通常通りに vuls scan を行ってください。

cronでの実行

定期的な脆弱性スキャンのためには、cron等での実行が必要です。 その際には、どのような通知が必要なのか(メールやSlack通知が必要か、 VulsRepoのWEB-UIで見えればいいのか、等)を検討する必要があります。

出力方法に合わせて reportオプション(およびconfig.toml)を調整します。

以下に、メール通知想定でまとめてみます。

config.toml
SMTPサーバー接続情報等を追加で記載します。

[servers]

[servers.vuls-server]
host        = "127.0.0.1"
port        = "local"
smtpAddr    = "your-smtp-server-IP/FQDN"
smtpPort    = "25"
from        = "from-mail@domain"
to          = ["to-addr@domain"]
cc          = ["cc-addr@domain"]
subjectPrefix = "[vuls]"

cron化用のスクリプト
Vulsでのスキャン前に、CVEデータベースの更新が必要です。 そのため、CVEデータベースのアップデートをしてからVulsでスキャンをする、というスクリプトを作ります。 対話的に実行している場合はあまり気にならないのですが、いくつかの設定が必要です。

  • Vulsは、bashで実行する必要がある
  • いくつかのコマンド(rmなど)が必要なので、vulsユーザのパスを流用するのが簡単です。
  • スキャンデータの出力はカレントディレクトリとなるので、明示的に出力先を定義します。
  • 同様にconfig.tomlファイルも、明示的に指定します。

reportは メール かつ 短文形式 としています。ここは好みで変えてください。

#!/bin/bash
PATH=/bin:/usr/bin:/usr/sbin
CONFIG=/opt/vuls/config.toml
RESULTS=/opt/vuls/results
CVEDB=/opt/vuls/cve.sqlite3
LOGDIR=/var/log/vuls
go-cve-dictionary fetchnvd -last2y -dbpath=$CVEDB -log-dir=$LOGDIR
go-cve-dictionary fetchjvn -last2y -dbpath=$CVEDB -log-dir=$LOGDIR
vuls scan -config=$CONFIG -results-dir=$RESULTS -log-dir=$LOGDIR
vuls report -config=$CONFIG -results-dir=$RESULTS -cvedb-path=$CVEDB -log-dir=$LOGDIR -to-localfile -format-json
vuls report -config=$CONFIG -results-dir=$RESULTS -cvedb-path=$CVEDB -log-dir=$LOGDIR -to-email -format-short-text

Vulsコミュニティテンプレートの構成について

Vulsを動作させる環境は、人によって様々です。今回提供されている コミュニティテンプレートはどのように構成されているかを確認したので、 ある程度Vuls利用経験がある方は参考にしてください。

OS等について

OS CentOS6.8
OS Update 2017/02/24時点の最新
DISK (/dev/sda1)として 15GB
Vuls build 2017/02/06 v0.2.0 1730caf
sudo /etc/sudoers.d/vuls にエントリがある

ディレクトリ等について

ディレクトリ構成は以下の通りです。

  • /home/vuls以下に、バイナリ等が配置されている
  • /opt/vuls以下に、configとデータ類が置かれている
  • vuls/go-cve-dictionaryは、/var/log/vuls 以下にログを出す
/
├─....
├── opt
│   └── vuls
│       ├── config.toml
│       ├── cve.sqlite3
│       ├── cve.sqlite3-shm
│       ├── cve.sqlite3-wal
│       └── results
│           ├── 2017-02-24T11:54:18+09:00
│           └── current -> /opt/vuls/results/2017-02-24T11:54:18+09:00
├── home
│   └── vuls
│       ├── README
│       └── go
│           ├── bin
│           ├── go1.7.5.linux-amd64.tar.gz
│           ├── pkg
│           └── src
.....

Vulsミートアップ「Vuls祭り #2」のご紹介 & 有用なリンク集

Vuls祭り、またやります!

2017/03/24 (金) に、二回目のUser MeetUpである「Vuls祭り #2」が開催されます。 コアな方も、そうでない方も有意義に過ごせると思いますので、ぜひ参加いただければと思います。
https://vuls-jp.connpass.com/event/51343/
私も、ローカルスキャンと脆弱性対応の考え方について、少しお話をする予定です。

有用な情報源(リンク集)

また、Vulsに関する有用なリンクをまとめておきます。

最後に

コミュニティテンプレートを利用して、まずはVulsを使ってみる、という目的で書いてみました。

Vulsは複数のサーバーをスキャンすることで、システム全体の脆弱性残存状況が分かります。 次回以降で、他のサーバーの脆弱性をスキャンする方法や、監視サーバー等の連携、ローカルスキャンモードについて 書いていけたらと思います。

そして、弊社 株式会社アールワークスでは、マネージド運用サービスにVulsを取り入れたプランを準備中です。 Vulsによる残存脆弱性情報の可視化をしながら運用ができます。

よろしくお願いいたします。

IDCFクラウドでセカンダリIPを取得する方法

IDCFクラウド API クラウド

こんにちは!ソリューションアーキテクト部の金杉です。よくお客様からご質問をいただくので、本日はIDCFクラウドでセカンダリIPを取得する方法について紹介しようと思います。

はじめに

1つのネットワークインターフェイスに複数IPを割り当てたいというケースは多々ありますよね。例えばバーチャルホストを使って同じサーバーで複数ドメインを運営する時や、Virtual IP (VIP)を用いて冗長構成を実現したい時など、様々なシーンでセカンダリIPが必要になってきます。このような技術を一般的に"IPエイリアス"と呼び、元から割り当てられているIPと追加で取得したIPをそれぞれ"プライマリIP"、"セカンダリIP"と呼んだりします。

IDCFクラウドではセカンダリIPの取得が可能です。このブログではIDCFクラウドのサーバーでセカンダリIPの取得およびセカンダリIPアドレスをグローバルIPアドレスと紐づける方法を紹介します。

セカンダリIP取得の2つのパターンと手順

セカンダリIPの取得には以下2通りのパターンがあります。パターンによって、手順が異なりますのでご注意ください。区別がつかない場合は、図1を参考にしてみてください。

パターン1 (手順1) セカンダリIP経由でインターネットと通信する場合
パターン2 (手順2) セカンダリIP経由でインターネットと通信しない場合

f:id:ykanasugi:20170223115939p:plain
   ▲図1 セカンダリIP取得の際の2つのパターン

パターンによって手順が異なる理由は、IDCFクラウドのネットワーク仕様です。IDCFクラウドでは、コンピューティング環境とインターネットの間に仮想ルーターが存在します。対象のセカンダリIPがインターネットと通信をする場合、仮想ルーターを経由するので、セカンダリIPとグローバルIPを紐づける必要があります。一方、セカンダリIPがインターネットと通信をする必要がない場合、これらの操作が不要になります。なので、パターンによってセカンダリIPを取得する手順を両方紹介します。

仮想マシンのデプロイに関してはこちらを参考にしてください。

方法① インターネットと通信する場合

今回は、Light.S1(1コア, 1GBメモリ)の仮想マシンを使ってセカンダリIPを取得していきます。ホスト名はsecondary-ip-test、OSはCentOS 6.8を使用します。プライマリIPは10.32.0.122がDHCPで設定されています。

使用できるIPアドレスの確認

セカンダリIPとして使用できるIPアドレスは限られているので確認をします。IDCFクラウドコンソールより、左メニューバー「ネットワーク」、ターゲットのネットワーク名、「IPアドレス一覧」をクリックします。

f:id:ykanasugi:20170228101049p:plain

DHCP範囲内(CIDRの前半)のIPアドレスが選択できます。つまり、このテーブルに表示されている割当済みのIPアドレスと、「割当範囲外」のIPアドレスを除いたすべてのIPアドレスがVIPとして割当可能です。セカンダリIPはDHCPもしくはスタティックで取得することが可能です。今回は10.32.0.100を指定して使います。

TIPS: DHCP範囲内のIPを選択する理由は?
今回、対象のセカンダリIPアドレスとグローバルIPアドレスを紐づける必要があります。紐づけるにはAPI経由でポートフォワードもしくはスタティックNATの2つの方法があるのですが、いずれも仮想ルーターに対しての操作になります。仮想ルーターに対してIPアドレス関連の操作を行う場合、その対象となるIPアドレスは仮想ルーターが認識できる必要があります。DHCP範囲外のIPアドレスは仮想ルーターでは認識できないので、ここではDHCP範囲内のIPアドレスを選択する必要があります。(でないと、グローバルIPアドレスと紐づけることができません。)

セカンダリIPアドレスの取得

手順①ではセカンダリIPアドレスの取得はCloudStack API経由で行います。IPアドレスの値は、先ほど確認した10.32.0.100をスタティックで付与します。APIに関しては、API Referencesをご参照ください。

IPアドレスを付与するに必要なコマンドはaddIpToNicです。必要なパラメーターおよび取得方法は以下になります。

パラメーター 取得方法 取得の際の注意点
nicid listNics 取得にあたってvirtualmachineidが必要です。virtualmachineidはlistVirtualMachinesで取得できます
ipaddress 指定 今回は10.32.0.100を入れます。指定しない場合はDHCPで付与されます

IPアドレスの取得が完了した後、グローバルIPとセカンダリIPをenableStaticNatコマンドでスタティックNATします。必要なパラメーターおよび取得方法は以下になります。
※通常のスタティックNATの設定はIDCFクラウドコンソールからもできますが、今回はセカンダリIPを紐づけるため、操作はAPI経由で行う必要があります。

パラメーター 取得方法 取得の際の注意点
ipaddressid listPublicIpAddresses 特になし
virtualmachineid listVirtualMachines 特になし
vmguestip 指定 先ほど指定した10.32.0.100を入れます。DHCPで割り当てた場合もIPアドレスを入力する必要があります

それでは、これらのコマンドを使って実際に操作をしてみましょう。

コマンドラインツールのインストール
APIを利用するにあたって、コマンドラインツールのインストールが必要になります。インストールするサーバーは、Pythonが動けばどのサーバーでもかまいません。APIのGetting Started ガイドに沿って「簡単な使い方:Step4」までを実行してください。

APIでセカンダリIPアドレスを取得

# 仮想マシンのid一覧を表示
[root@API-Server ~]# cloudstack-api listVirtualMachines -t displayname,id
+---------------------+--------------------------------------+
|    displayname      |                  id                  |
+---------------------+--------------------------------------+
|  secondary-ip-test  | dd41b1a8-1c4a-48fd-b062-2ccab4c0ffc6 |
+---------------------+--------------------------------------+
 
# secondary-ip-testのNIC idを表示
[root@API-Server ~]# cloudstack-api listNics --virtualmachineid dd41b1a8-1c4a-48fd-b062-2ccab4c0ffc6 -t ipaddress,id
+-------------+--------------------------------------+
|  ipaddress  |                  id                  |
+-------------+--------------------------------------+
| 10.32.0.122 | 0f25accf-06f8-4722-beda-508cc832c4ef |
+-------------+--------------------------------------+
 
# secondary-ip-testのNICにセカンダリIPアドレスを指定して割り当てる
[root@API-Server ~]# cloudstack-api addIpToNic --nicid 0f25accf-06f8-4722-beda-508cc832c4ef --ipaddress 10.32.0.100

# もう一度secondary-ip-testのNICの情報を表示
[root@API-Server ~]# cloudstack-api listNics --virtualmachineid dd41b1a8-1c4a-48fd-b062-2ccab4c0ffc6
 (略)
 "secondaryip": [
  {
    "id": "fadd1502-3aaa-4576-a05a-0d4eb1762265",
    "ipaddress": "10.32.0.100"
  }
]
(略)

IDCFクラウドコンソールでグローバルIPを取得する
まずは、スタティックNATで使用するグローバルIPをIDCFクラウドコンソールより取得します。標準で1個付与されているグローバルIPはスタティックNAT用に使用できませんのでご注意ください。

IDCFクラウドコンソールにログインしたら、対象のリージョン→コンピューティングを選択し、左の「IPアドレス」タブをクリックします。画面の右上にある「IPアドレス取得」をクリックします。 f:id:ykanasugi:20170221105603p:plain

続いて、ポップアップが出てきたらIPアドレスの表示名と対象のネットワークを選択します。入力が終わったら右下の「取得する」をクリックします。 f:id:ykanasugi:20170221105948p:plain

先ほどのIPアドレスの画面に戻ったら、新たにグローバルIPが追加されているのが確認できます。現在「NAT」の欄は"なし"となっていますが、後ほど対象の仮想マシン名(secondary-ip-test)が表示されます。

f:id:ykanasugi:20170221112948p:plain

APIでセカンダリIPをグローバルIPとスタティックNATをする
それでは、先ほど取得したグローバルIPを10.32.0.100とスタティックNATします。

# 現在あるグローバルIPとそのidを表示
# 先ほど取得した210.140.43.145を使う
[root@API-Server ~]# cloudstack-api listPublicIpAddresses -t ipaddress,id
+----------------+--------------------------------------+
|   ipaddress    |                  id                  |
+----------------+--------------------------------------+
| 203.137.176.8  | eaa68c54-29a9-4ad1-bd93-32740e8bc15d |
| 210.140.42.154 | 7b469138-8504-4133-9c73-2d28ebde7aba |
| 210.140.43.145 | 17efd86a-9e2e-452a-ade9-d8b11610a091 |
+----------------+--------------------------------------+

# スタティックNATを有効化
[root@API-Server ~]# cloudstack-api enableStaticNat --ipaddressid 17efd86a-9e2e-452a-ade9-d8b11610a091 --virtualmachineid dd41b1a8-1c4a-48fd-b062-2ccab4c0ffc6 --vmguestip 10.32.0.100
{
  "enablestaticnatresponse": {
    "success": "true"
  }
}

スタティックNATのを確認
スタティックNATの設定が完了したら、ポータルから確認してみましょう。「NAT」の欄にsecondary-ip-testと表示されていますね。これで設定は完了です。 f:id:ykanasugi:20170221161116p:plain

手順② インターネットと通信しない場合

手順②ではセカンダリIPアドレスの取得は直接OS内で指定して行います。手順①より簡単です。このブログではCentOS6系とCentOS7系両方のやり方を紹介します。

使用できるIPアドレスの確認
セカンダリIPとして使用できるIPアドレスは限られているので確認をします。IDCFクラウドコンソールより、左メニューバー「ネットワーク」、ターゲットのネットワーク名、「IPアドレス一覧」をクリックします。

f:id:ykanasugi:20170227091449p:plain

ここで表示されている「割当範囲外」のIPアドレスがすべてセカンダリIPとして指定できます。(「利用不可」と書かれている最後の10個のIPアドレスだけはIDCFクラウド側で使用するため割当はできません)なので、この例では10.32.4.1を使います。

セカンダリIPアドレスの取得

CentOS 6系とCentOS 7系を例に手順を紹介します。

CentOS 6系の場合
今回は、Light.S1(1コア, 1GBメモリ)の仮想マシンを使ってセカンダリIPを取得していきます。ホスト名はsecondary-ip-test-cent6、OSはCentOS 6.8を使用します。プライマリIPは10.32.0.122がDHCPで設定されています。

#ifcfg-eth0:1の設定ファイルを作成
[root@secondary-ip-test-cent6 ~]# cp /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-eth0:1

#IPアドレスをDHCP取得ではなく、スタティックに書き込む
[root@secondary-ip-test-cent6 ~]# vi /etc/sysconfig/network-scripts/ifcfg-eth0:1
DEVICE=eth0
ONBOOT=yes
IPADDR=10.32.4.1
NETMASK=255.255.248.0

#ネットワークの再起動
[root@secondary-ip-test-cent6 ~]# service network restart

#eth0の情報確認
[root@secondary-ip-test-cent6 ~]# ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 02:03:01:be:00:05 brd ff:ff:ff:ff:ff:ff
    inet 10.32.0.122/21 brd 10.32.7.255 scope global eth0
    inet 10.32.4.1/21 brd 10.32.7.255 scope global secondary eth0
    inet6 fe80::3:1ff:febe:5/64 scope link 
       valid_lft forever preferred_lft forever

10.32.4.1がちゃんと設定されていました。

CentOS 7系の場合
今回は、Light.S1(1コア, 1GBメモリ)の仮想マシンを使ってセカンダリIPを取得していきます。ホスト名はsecondary-ip-test-cent7、OSはCentOS 6.8を使用します。プライマリIPは10.32.0.209がDHCPで設定されています。

#まずは現在の状態を見てみます
[root@secondary-ip-test-cent7 ~]# ip addr show
(略) 
2: eno16777984: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 02:03:01:be:00:06 brd ff:ff:ff:ff:ff:ff
    inet 10.32.0.209/21 brd 10.32.7.255 scope global eno16777984
       valid_lft forever preferred_lft forever
    inet6 fe80::3:1ff:febe:6/64 scope link 
       valid_lft forever preferred_lft forever

#nmcliコマンドでセカンダリIPを追加
[root@secondary-ip-test-cent7 ~]# nmcli connection modify eno16777984 +ipv4.addresses  "10.32.4.1/21"

#ネットワークを再起動する
[root@secondary-ip-test-cent7 ~]# systemctl restart network

#再度NICの状態を確認
[root@secondary-ip-test-cent7 ~]# ip addr show
(略)
2: eno16777984: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 02:03:01:be:00:06 brd ff:ff:ff:ff:ff:ff
    inet 10.32.0.209/21 brd 10.32.7.255 scope global eno16777984
       valid_lft forever preferred_lft forever
    inet 10.32.4.1/21 brd 10.32.7.255 scope global secondary eno16777984
       valid_lft forever preferred_lft forever
    inet6 fe80::3:1ff:febe:6/64 scope link 
       valid_lft forever preferred_lft forever

こちらでも10.32.4.1がちゃんと設定されていますね。

まとめと注意点

セカンダリIPを使いたい時は、まずはどのような利用をするかに沿って方法を選択しましょう。ちなみに以前セカンダリIPを使ってLVSを冗長化する記事も書いたのでご参考ください。

手順①のAPI経由で取得したセカンダリIPの扱いには、2つ注意点がありますのでご参考ください。

  1. セカンダリIPはIDCFクラウドコンソールからの管理ができないので、ご自身での管理となります。
  2. セカンダリIPをグローバルIPとスタティックNATした場合、APIでスタティックNATを解除してから仮想マシンを削除するようにしてください。スタティックNATの設定解除せず、そのまま仮想マシンを削除してしまうとシステム側からスタティックNATが削除できなくなってしまいます。

方法2については特に注意点はないのですが、紹介したCentOS6と7の方法は両方ともネットワークの再起動が伴うため、動的にIPを追加したい場合はip addr addコマンドなどで追加することも可能です。

ぜひ、試してみてください。

IDCFクラウドでのマルチキューネットワーク

IDCFクラウド

f:id:tafujish:20170127205753p:plain

仮想環境や古いサーバーだと上記画像のように、CPU使用率が特定のコアに偏ることがあると思います。特に2番のCPUのsi(ソフトウェア割り込み)の値のみ大きいです。このような場合、マルチキューネットワークに対応することで複数のCPUコアを利用することができるためネットワーク性能をスケールすることができます。

この話はしばしば質問いただきますが、IDCFクラウドの仮想マシンのNICはRSS(Receive Side Scaling)に標準で対応しているので、マルチキューネットワークのためにこれといった操作や設定は不要です。

「以上です。」
で終わってしまいそうな話ですが、以下ではもう少し踏み込んでみるので、CPUの各コアの利用が偏っている場合は次を参照ください。だいたい多い話として、irqbalanceが入っていなかったり、ダイナミックスケール後の話だったり、ISOから作った仮想マシンだったりします。

1) RSSに対応しているか確認するには

RSSはNIC側で複数のキューを持ち、複数のCPUコアを活用できます。

IDCFから提供しているテンプレートから仮想マシンを作成すると、標準でRSSに対応したNICである「vmxnet3」が搭載されています。vmxnet3であることの確認は、

# ethtool -i ens160
driver: vmxnet3
version: 1.4.7.0-k-NAPI
~略~

※ens160はネットワークインターフェース名(eth0等適宜置き換えてください)

driverがvmxnet3であれば、このNICはRSS対応となります。

では、具体的にマルチキューになっているか確認しましょう。

# ls /sys/class/net/ens160/queues/
rx-0  rx-1  rx-2  rx-3  tx-0  tx-1  tx-2  tx-3

※ens160はネットワークインターフェース名(eth0等適宜置き換えてください)

rx-0からrx-3の4つが受信キュー、tx-0からtx-3の4つが送信キューです。
仮想マシンのCPUのコア数と同じ数のキューが有効になっています。(この仮想マシンはHighcpu.L8の4コアマシン)

この4つのキューが、どこのCPUコアに割り当てられてるかは次のように確認できます。

# cat /proc/interrupts | grep ens160
  56:         39          0          0      44516   PCI-MSI-edge      ens160-rxtx-0
  57:          7      44132          0          0   PCI-MSI-edge      ens160-rxtx-1
  58:         16          0      44175          0   PCI-MSI-edge      ens160-rxtx-2
  59:         28          0          0      44739   PCI-MSI-edge      ens160-rxtx-3
~略~

※ens160はネットワークインターフェース名(eth0等適宜置き換えてください)

割り込みのカウントが上がっているところを見ると、0番のキューはCPUの3番、1番のキューはCPUの1番、2番のキューはCPUの2番、3番のキューはCPUの3番に割り当てられてます。
この環境はCentOS7.3ですが、0番のCPUが使われておらず、3番のCPUに2つのキューが割り当てられています。このあたり、気になる方は、次の 2) を参照ください。

では、この環境に負荷をかけて、CPUの使用率を確認します。

f:id:tafujish:20170127205755p:plain

上記のキューの割り当ての通り、0番のCPUの負荷は低く、3番のCPUの負荷が高くなっています。
ここまで確認したように動いていれば、RSSが正常に機能しています。
NICがvmxnet3で、キューの数もCPUコア数に応じた数があるのに、CPUの使用率が異なる場合、キューが各CPUに割り当てられていない可能性があります。そのようなときはirqbalanceをyumやaptでインストールして動かしてみてください。

執筆時点のIDCFクラウドの標準テンプレートだと、CentOS6.xと7.xでははじめからirqbalacneがインストールされていますが、Ubuntu16.04ではインストールされていません。

2) CPU0番コアが使われていないとき

先述のとおり、RSSが機能しており、irqbalanceが各CPUコアにキューを割り当てているのに、0番のCPUが使われないのは、irqbalanceが0番のCPUに割り当てないためです。
CnetOS6.xでは0番にも割り当てますが、CentOS7.xやUbuntu16.04では0番に割り当てられません。

偏りが問題ないレベルであれば、そのまま利用いただいて問題ないですが、カツカツにCPUリソースを消費していて偏りが困る場合は、キューの割り当て先CPUを手動で変更することもできます。

まずは、割当先を変更したい0番のキューのIRQ番号確認します。ここでは56番です。

# cat /proc/interrupts|grep ens160
  56:         39          0          0     268151   PCI-MSI-edge      ens160-rxtx-0
~略~

※ens160はネットワークインターフェース名(eth0等適宜置き換えてください)

次に現在の割当先を念のため確認します。ここで先ほど調べたIRQ番号を入れます。ここでは、「8」となってますがビットで記載されているので、3番のCPUに割り当てとなっています。
(ちなみに、0番のCPUは「1」、1番のCPUは「2」、2番のCPUは「4」となります)

# cat /proc/irq/56/smp_affinity
00000000,00000000,00000000,00000008

0番のCPU(値としては「1」)に割り当て、確認します。

# echo 1 > /proc/irq/56/smp_affinity
# cat /proc/irq/56/smp_affinity
00000000,00000000,00000000,00000001

この状態で負荷をかけるときれいに分散されました。

f:id:tafujish:20170127205757p:plain

この設定はOS再起動で消えてしまうので、必要だったらOS起動時のスクリプトに記載ください。
また、irqbalanceがデーモンとして動いていると変更した設定を戻されてしまうので、irqbalanceのサービスを止めるかONESHOTの設定にする必要があります。

3) ダイナミックスケール後の対応

IDCFクラウドでダイナミックスケールした後、増えたCPUのコアがちゃんと使われていないというような質問をしばしばいただきます。

実はダイナミックスケールによりCPUのコアが増えたとしても、RSSのキューの数が増えないため、増えたCPUコアをNICが使うことはありません。
増えたCPUコア分のキューを増やすには、vmxnet3のモジュールをいったん削除し、再度追加することで認識できます。

# modprobe -r vmxnet3; modprobe vmxnet3

ただ、この方法だとモジュールを削除するので瞬断が発生します。
それが難しい場合は、以下の4)のようにRPS/RFSでマルチキュー化でしのぎ、次回OS再起動時にRSSに戻るという方法もあると思います。

4) RSS対応してないときはRPS/RFSで

RSSはNICの方が対応しているマルチキューネットワークであり、NIC(今回だとvmxnet3)が対応している必要があります。IDCFクラウドでは、vmxnet3以外のNICも利用可能です。

  • テンプレートインポート時にe1000かpcnet32を選択することもできます
  • ISOインストールでの仮想マシンはデフォルトでe1000となります

このように、vmxnet3以外のときは、OS側でマルチキューネットワークに対応させます。具体的には、 RPS(Receive Packet Steering)、RFS(Receive Flow Steering)です。

では具体的な設定を紹介します。
例えば、以下のようなe1000のNICでキューが1つしかない、4コア仮想マシンの環境があったとします。デバイス名はens35とします(eth0等適宜置き換えてください)。

# ethtool -i ens35
driver: e1000
version: 7.3.21-k8-NAPI
~略~

# ls /sys/class/net/ens35/queues/
rx-0  tx-0

まずはRPSの設定です。入力している「f」は4コアすべて利用するときでビット計算となってます。例えば、2コアのときは「3」、8コアのときは「ff」となります。

# echo f > /sys/class/net/ens35/queues/rx-0/rps_cpus

次にRFSです。rps_sock_flow_entriesの値は、一般的に「32768」が推奨されています。
一方で、rps_flow_cntは、rps_sock_flow_entries÷受信キューの数となります。e1000のこの環境ではキューは1つのため、rps_sock_flow_entriesと同じ値となります。

# echo 32768 > /proc/sys/net/core/rps_sock_flow_entries
# echo 32768 > /sys/class/net/ens35/queues/rx-0/rps_flow_cnt

以上ですが、上記設定はネットワークインターフェース毎に設定が必要なので、複数NICがある場合はその分実行ください。また、これらの設定はOS再起動で消えてしまうので、必要だったらOS起動時のスクリプトに記載ください。

5) e1000のテンプレートをvmxnet3に変える

先述のとおり、e1000でもRPS/RFSでマルチキューネットワークは利用できますが、設定が面倒だとか何らかの理由でvmxnet3に置き換えたいときもあると思います。

そのときは、テンプレートを一度エクスポートしていただき、再度インポートしていただければ、インポート時の設定で下図のようにNICの種類を指定することが可能ですので、こちらもご検討ください。

f:id:tafujish:20170127205758p:plain

まとめ

長くなりましたが、基本的にはRSS標準対応なので、手間なくそのままご利用いただけます。もしCPUのコアが偏っているようであれば、上記ご参照ください。

コーポレートサイトのセキュリティ対策は万全ですか?

IDCFクラウド DNS セキュリティ

はじめましてみなさん、コンテンツマーケティング部の河田です。
おもにIDCフロンティアのコーポレートサイトの運営を担当しています。

f:id:dkawata:20161226185447p:plain

当社のことをみなさんに知っていただく看板サイトとして、日々、新サービスの紹介やイベント、キャンペーン情報などを発信し続けています。
本日は、IDCFクラウド上で稼働しているコーポレートサイトを運用し続けるための仕組みを次のポイントに分けてわかりやすくご紹介していきたいと思います。

はじめに

今回お伝えしたい内容がこちらです。

  • 24時間365日運営できるサイト作り
  • サイトを守るために必要な3つの対策
    • GSLBによる広域負荷分散
    • DDoS対策サービスの導入
    • WAFの活用
  • 実際に障害が起こってしまったら
  • 最後に

前提となるWeb上の脅威のお話から、具体的な対策方法、障害発生時への備えまで一連の流れでご紹介したいと思います。では早速、本題に入りましょう。

24時間365日運営できるサイト作り

Webの世界にはリアル社会のように年末年始の休業期間などはありません。 基本的に24時間365日、サイトを運用し続けることが前提となります。
そしてWeb上でサービスを提供しているかぎり尽きないのがサイバー攻撃の脅威です。
中でもコーポレートサイトのような会社のブランディングに直結するサービスには DDoS攻撃などが猛威を振るってきます。 TCP・SYNフラッド、UDPフラッド、DNSアンプ、Low and Slow攻撃など、その種類は上げればきりがないくらい存在します。
また、それぞれの攻撃が狙うターゲットレイヤーも異なり、その規模もどんどん大きくなってきています。

こうした悪意のある攻撃からサイトを守るためには、単純にサーバーを強化するだけでは対策不足です。ネットワークインフラからサーバーまで一貫した対策が必要になります。

サイトを守るために必要な3つの対策

IDCFのコーポレートサイトは、これからご説明する3つのサービスを用いてセキュリティ対策を実現しています。
では、実際にどのような取り組みをしているのか簡単にご紹介していきます。

1)GSLBによる広域負荷分散

サイバー攻撃に関わらず、人為的なミスや大規模災害などが起きて、サーバーに何らかの障害が発生した場合、ただちにGSLBは登録されているディザスタリカバリ(DR)サイトへ自動でアクセスを切り替え、ダウンタイムを 最小限に抑えてくれます。
通常のロードバランサーと違い、東西の拠点でロードバランシングを行うため、より一層可用性が担保されます。アクセス数の多い都心部からのレイテンシを考慮し、プライマリサイトを東日本に構築していることもポイントです。
そして、拠点間でのコンテンツ同期やバックアップを行い、さらにプライベートコネクト接続で セキュアな通信網を利用すればベストです。

f:id:dkawata:20170106140952p:plain
▲GSLBによるDRサイトへの自動切り替わりイメージ

2)DDoS対策サービスの導入

このDDoS対策サービスというのは、トラフィックがサーバーに届くより前の段階のネットワーク領域でDDoS攻撃を緩和、防御してくれます。

もう少し詳しく説明すると、以下のフローを自動で行います。
1. ネットワーク上の振る舞いから悪意のあるトラフィックを検知する
2. そのトラフィックを遮断するためのシグネチャを自動生成(動的シグネチャ
3. フィルタリングを実行

既知の攻撃手法に対しての防御は不正侵入検知/防御サービス(IDS/IPS)で対応可能ですが(静的シグネチャ)、未知の攻撃や巧妙に細工された攻撃にはこのDDoS対策サービスが特に効果を発揮します。

※静的シグネチャとは、既知の攻撃パターンをデータベース化して管理した上で、該当する攻撃をフィルタリングする方式です。

3)WAFの活用

WAFとはWeb Application Firewallの略称で、一般的によく知られているFirewallがポート、IP制限などのネットワークレイヤーの不正アクセスを防ぐのに対して、WAFは「SQLインジェクション」「XSS」などのWebアプリケーションを狙った攻撃を防御してくれます。

例えば、お問い合わせなどのフォームからサーバーへ送られる入力データのチェックを行い、不正なデータが渡されないようにします。つまりサーバーとクライアントの間に立って通信を遮断し、Webアプリケーションを防御してくれます。

しかしながら、WAFを導入すればすべてのWebアプリケーションの脆弱性対策ができるかというと、答えはNOです。 あくまで暗号化された通信(SSL)上でのセキュアなプログラミングや適切なサーバー設定の漏れを補完することが目的です。

f:id:dkawata:20161226185515p:plain
▲各レイヤーによりサイバー攻撃を防御する対象が異なる

こうしたネットワークサービスを導入することで、一定のサイバー攻撃からサイトを守ることができます。 しかもその負荷を専用機器でまかなうことができるため、Webサーバーに無駄な負荷をかけずに済みます。
SSLの暗号化・復号処理をサーバーではなく、ロードバランサーで行っていることもポイントの一つです(SSLアクセラレーション)。 普段何気なくアクセスしているコーポレートサイトも、コンテンツへ到達するまでには 上図のような様々なサービスを通過して閲覧できているワケですね。

実際に障害が起こってしまったら

ここからは人や組織の対策です。
あまり考えたくないことですが、実際に問題や障害が発生してしまった時の行動を緊急時対応マニュアルとしてフローチャート形式でまとめることや、エスカレーション先を決めた表を作成する必要があります。
この時、自分ひとりですべての作業を差配している人は少ないと思います。複数の部署をまたいだ連携が必要になってくるハズです。そのため、物事の決定権が誰にあるのかを事前に決めておくことは非常に重要です。できれば担当部署だけでなく、担当者名まで決めておくことができれば安心です。
またその代理や、最悪、誰とも連絡がつかなかった場合などその条件は多岐に渡りますが、まずは自分の上司など身近なところから決めて行き、表を完成させていきましょう。

まとめ

今回は少し駆け足でコーポレートサイトの全体像をお伝えしました。
以上のことを踏まえてIDCFのコーポレートサイトはざっくりと下図のような構成になっています。

f:id:dkawata:20161227171522p:plain

普段は個々のサービスとして独立して説明する機会が多いと思いますが、このように一連の流れで説明することで、それぞれのサービスが担当する守備範囲がわかりやすくなったのではないでしょうか。

要点をまとめてみます。

  • GSLBによるDRサイト構築
  • DDoS対策サービスを含むネットワークサービス(FW、IDS/IPS、WAF、LB)の導入
  • SSLによる通信の暗号化
  • セキュアなプログラミングや適切なサーバー設定
  • コンテンツの同期とバックアップ
  • 障害時の対応マニュアルの作成

これらがすべて揃って初めて24時間365日運営できるサイト作りが実現することになります。

最後に、今回取り上げたこれらのサービスを実際使ってみたいという方へのお知らせです。
中でもIDCFクラウド上で導入可能なGSLB(DNS)プライベートコネクトILBならすぐにでも対策を始めることができます。 また、お申込みベースでDDoS対策サービスを含むIDCFネットワークサービスも利用可能です。

これを機にみなさんが運営されているサイトのリスクマネジメント対策を見直してみてはいかがでしょうか?

超簡単〜ILBをMackerelで監視してみよう

ILB Mackerel IDCFクラウド

こんにちは!ソリューションアーキテクト部の金杉です。

12/15(木)のアップデートで、IDCFクラウドILBのノードに対してMackerelを使った監視ができるようになりました。今まで、ILBに対しての監視サービスは提供されていなかったので、これでパフォーマンス調査やトラブルシューティングがだいぶ楽になりますね。

f:id:ykanasugi:20161220120547p:plain

ちなみにILBもMackerelも過去の記事で紹介してきましたが、ILBとはIDCFクラウド上で動作するオートスケール可能なロードバランサーで、Mackerelは株式会社はてなが提供するエージェント型のリソース監視ツールです。詳しくは、以下の記事を参考にしてください。

Mackerel関連記事
Mackerelブログリレー『第1回 新人がIDCFクラウドでMackerelを使ってみた』 Mackerelブログリレー『第2回 新人がMackerelにホスト登録してみた』

ILB関連記事
ILBを使ってWebサーバーをバランシング!構成事例もご紹介

はじめに

今回のアップデートのポイントを3つにまとめてみました。 ポイントの紹介後に、早速導入をしてみます。

1. Mackerelの導入が簡単かつ無料

ILBに対してのMackerel導入はとても簡単で、エージェントのインストールやコンフィグの書き換えなどの手間は一切不要です。設定の際にチェックを一つ入れて、APIキーを貼り付けるだけのめちゃ楽作業です。そして、無料です😉

また、Mackerelインターフェイスでのメトリックグラフもすでに定義済みなので、手動で設定する必要もありません。現在は、以下3つの項目が見れるようになっています。項目ごとの説明はステップ③を参考にしてください。
1) Health Check Errors
2) Sessions
3) Traffics

2. UXを重視した見せ方

Mackerelを使って監視をする時、通常はサーバー1台ごとにリソースグラフが表示されますが、ILBでMackerelを使うとすべてのノードの状態をまとめて表示してくれます。

前提として、ILBは負荷に応じてオートスケールする(ノード数が増える)という特徴があります。しかし、ILBを監視する立場になると、ノード単体のリソース状況よりも全体のリソース状況が気になりますよね。よって、今回のアップデートではILBの全ノードを一体化したUX重視な見せ方を採用しています。

3. 稼働中のILBにも適用OK

「ええ!すごいじゃん!でもILBずっと昔に立てちゃったよ...」という方も、心配不要です!Mackerelの実装は、稼働中のILBに対しても可能です👌 新規ILBとほぼ同様の方法で導入できるので、同じ手順を参考にしてください。

ILBにMackerelを導入してみる

それでは、早速ILBにMackerelをインストールしてみましょう。インストールには必ずMackerelのAPIキーが必要になってくるので、まずはMackerelの画面でAPIキーを確認し、その次にILBに対してインストールの手順を紹介します。

IDCFクラウドコンソールの上にカーソルを移動するとサービス一覧がでるので、そこからMackerelとILBの管理画面が開けます。 f:id:ykanasugi:20161219164644p:plain

①事前準備〜Mackerel API Keyを確認〜

まずはMackerelの管理画面に移動します。IDCFクラウドからはシングルサインオンができるので、便利です。新規登録ができていない方は、ぜひこれを機会に登録してみてください。無料で使える特典プランもあります。

左のメニューから対象のオーガニゼーションを選択します。続いて「APIキー」のタブをクリックします。ここでAPIキーのコピーができます。一番右のアイコンをクリックするとそのままコピーしてくれますのでぜひ活用ください。 f:id:ykanasugi:20161219164700p:plain

これでMackerelのAPIキーの確保ができましたので、ILBの設定に移ります。

②ILBにMackerelを導入

新規ILBに対してMackerelを導入する場合、まずILBの作成を行います。画面右上にある「ILB作成」をクリックします。 既存のILBの場合は、直接対象となるILBのILB名をクリックし、直接オプション入力のステップに移ります。

●パラメーター入力
ロードバランサーのネットワーク、FQDN、Configurationなどのパラメーターを入力します。設定で迷ったら、こちらの記事を参考にしてみてください。 f:id:ykanasugi:20161215210717p:plain

●オプション入力
一通り設定が終わったら、オプションの入力をします。Mackerelのインストールもここで選択します。
「リソース監視」の欄にチェックを入れたら、APIキーの入力欄が表示されるので、先ほど確認したMackerelのAPI Keyをペーストします。Firewallの設定も適宜入れます。終わったら、「確認画面へ」をクリックし、問題なければ作成をします。 f:id:ykanasugi:20161219164730p:plain

③MackerelでILBの様子を確認

ILBの画面にもどって、作成したILBのステータスがRunningになったらMackerelの画面で確認してみましょう。

Mackerelのダッシュボードで「Hosts」を確認すると、ILBのFQDNが表示されていて、ステータスがWorkingになっているはずです。 f:id:ykanasugi:20161219164754p:plain

上図のホスト名をクリックすると、各種メトリックグラフが見えます。例のILBでは、Webサーバー2台を分散させています。(10.15.0.98と10.15.0.245) f:id:ykanasugi:20161219113750p:plain   ▲Health Check Errorsのメトリック
ILBから分散先サーバーに対してのヘルスチェックの結果を見ることができます。値が1の時はヘルスチェック結果がエラーで、値が0の時はヘルスチェックが正常に通っているということになります。

f:id:ykanasugi:20161221103844p:plain   ▲Sessionsのメトリック
分散先サーバーごとのセッション数を見ることができます。さらにcurrentとrateで分かれており、currentは現在のセッション数で、rateは秒間の新規セッション数を表しています。
また、totalの値も見ることができます。currentのtotal値は分散先サーバーの合計のセッション数で、rateのtotal値は分散先サーバーの合計の新規セッション数です。

f:id:ykanasugi:20161221103849p:plain   ▲Trafficsのメトリック
分散先サーバーごとの秒間トラフィックを見ることができます。さらにtxBytesとrxBytesと分かれており、txBytesは秒間送信バイト数で、rxBytesは秒間受信バイト数を表しています。 (※単位はMbpsではなく、Mbytes/secなのでご注意くださいね)
トラフィックも同じく、totalの値を見ることができます。txBytesのtotal値は、各サーバーの秒間送信トラフィックの合計値なので、ILBの秒間トラフィックとも解読できます。今ままではIDCFクラウドのビリングより合計転送量のみ確認できましたが、今後は秒間トラフィックも確認できるのでとても便利です!

これで、ILBに対してのMackerelの導入は完了となります。監視ルールでもこれらのメトリックに対して設定を行えます。

さいごに

ILBのリソース状況が知りたい!という時は、ぜひこの記事に沿ってMackerelをインストールしてみてください。メリットは先ほどもありました通り、以下3点です。
1) 簡単かつ無料👍
2) 見やすい👍
3) 新規/既存のILBどちらも適用可能👍

Mackerelについては以前もたくさん紹介してきましたが、毎日進歩しています。IDCFクラウドとも非常に相性がいいので、ぜひ仮想ルーターやホスト監視などでも活用してみてください。

IDCFクラウドのGPU搭載仮想マシンを使い始める手順~CUDAインストール編~

クラウド IDCFクラウド GPU

2016年11月25日、IDCFクラウドに新しいリージョンが追加され、あわせて「GPU BOOSTタイプ Tesla M40」がリリースされました。 www.idcf.jp

ディープラーニング等、通常のCPUでは計算性能が足りなくなるシーンでの利用を想定したGPU搭載仮想マシンです。本記事では、GPUを使い始めるための手順について紹介いたします。

f:id:kkamiyakenshiroh:20161207155756p:plain

1. GPUコンピューティング

GPUコンピューティングとは

主に3DCGなどの画像処理を行うデバイスであるGPUを、計算分野で利用することをGPUコンピューティングといいます。 昨今の「ディープラーニング(深層学習)」「ビッグデータ」「IoT」「AI(人工知能)」「機械学習」など注目ワードには、GPUコンピューティングが密に関係しています。

なぜGPUを利用するのか

CPUとGPUは、それぞれ下記の特徴をもちます。

  • CPU:数コア~数10コアを持ち、逐次処理が得意
  • GPU:数百コア~数千コアを持ち、並列処理が得意

このそれぞれの特徴を活かして、逐次処理をCPU、並列処理をGPUに割り当てることで、CPU単体よりも圧倒的な速度で演算することができます。

2. IDCFクラウド GPU BOOSTタイプの特長

大容量GPUメモリ搭載のGPUを採用

「GPU BOOSTタイプ Tesla M40」は名前の通りNVIDIA Tesla M40 (24GBメモリ版)を搭載しています。ディープラーニングなどのGPUを用いた計算では、GPUメモリ容量がボトルネックになりやすいため、Tesla M40の中でもGPUメモリが多い24GB版を採用しています。

専有タイプで他仮想マシンからの性能影響無し

GPU BOOSTタイプは1物理サーバーに1台だけ仮想マシンが稼働する占有タイプとして提供しているため、共有環境で発生しうる、他の仮想マシンからの負荷による影響を受けず、物理サーバーの全性能を使う事が出来ます。

IDCFクラウドの通常の仮想マシンと同じ操作で利用可能

GPU BOOSTタイプは通常の仮想マシンと全く同じ操作で作成・削除などが実施できます。また課金についても上限金額ありの従量課金となっております。ただし、ハードウェア占有タイプである事と、GPUを仮想マシンに直接認識させているため、以下の制限があります。

  • 仮想マシンが起動した状態でのボリュームのスナップショットの取得ができません
  • 物理サーバーが故障などで停止した場合の別サーバーへのフェイルオーバー機能はありません

3. GPUを利用するためのCUDAライブラリの導入方法

Tesla M40などのNVIDIA社製GPUを用いて計算を行うためには、GPUのドライバと計算を行うためのCUDAライブラリを導入する必要があります。本記事では、IDCFテンプレート「CentOS 7.2 64bit」仮想マシンを前提に、CUDAライブラリのインストール手順を解説いたします。

GPU BOOSTタイプの仮想マシンの作成

GPU BOOSTタイプは現時点では「東日本リージョン2(jp-east-2)」でのみ提供しています。そこで、仮想マシンを作成するためにIDCFクラウドのポータルから東日本リージョン2のコンピューティングを選択します。

f:id:anikundesu:20161201114304p:plain

次に、仮想マシン一覧画面から「仮想マシン作成」をクリックします。

f:id:anikundesu:20161201114340p:plain

仮想マシン作成画面で、ゾーンを「weber」もしくは「lux」を選択し、次の「マシンタイプ」で「GPU」タブをクリックします。するとマシンタイプ一覧に「gpu.7XLM40」が表示されるので、選択します。

f:id:anikundesu:20161201114521p:plain

以後は通常の仮想マシンと同じように設定します。ここではテンプレートとして「CentOS 7.2 64bit」を利用して、設定を確認の上で作成を実行します。

CUDAインストール用のレポジトリRPM取得とインストール

NVIDIA社のCUDA Toolkit配布サイトから、次の図のようにOS等を選択します。そして図内の「rpm (network)」をクリックし、RPMをダウンロードします。

f:id:anikundesu:20161129201908p:plain

ダウンロードしたRPMをGPU BOOSTタイプの仮想マシンにアップロードし、以下のコマンドでインストールを行います。

$ sudo rpm -i cuda-repo-rhel7-8.0.44-1.x86_64.rpm
警告: cuda-repo-rhel7-8.0.44-1.x86_64.rpm: ヘッダー V3 RSA/SHA512 Signature、鍵 ID 7fa2af80: NOKEY
(以下省略)

CUDAライブラリのインストール

CUDAおよびNVIDIAドライバを配布するレポジトリ情報が登録されたので、次はCUDAのインストールを行います。

$ sudo yum clean all
読み込んだプラグイン:fastestmirror, remove-with-leaves, show-leaves
リポジトリーを清掃しています: base cuda epel extras updates
Cleaning up everything
Cleaning up list of fastest mirrors

$ sudo yum install cuda
(以下省略、大量のパッケージが導入されます)

万一、パッケージのダウンロードやインストールが一部失敗するようなことが発生した場合は、yum clean allから再インストールをもう一度実行します。インストールが無事に完了したら、仮想マシンのOS再起動を実行します。

GPUが認識された事の確認

NVIDIAドライバが導入され、正常に認識されると、nvidia-smiコマンドでGPUのステータスが確認できます。

# nvidia-smi
Tue Nov 22 15:00:36 2016       
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 367.48                 Driver Version: 367.48                    |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  Tesla M40 24GB      Off  | 0000:03:00.0     Off |                    0 |
| N/A   39C    P0    60W / 250W |      0MiB / 22939MiB |    100%      Default |
+-------------------------------+----------------------+----------------------+
                                                                               
+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID  Type  Process name                               Usage      |
|=============================================================================|
|  No running processes found                                                 |
+-----------------------------------------------------------------------------+

なお、正常にGPUが認識されていない場合は、以下のようなエラーが表示されます。

# nvidia-smi 
modprobe: FATAL: Module nvidia not found.
NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.

再起動後も上記のエラーが表示された場合、もう一度OS再起動をすると認識される場合があります。

以上でGPUを利用するためのCUDAライブラリの導入が完了しました。ディープラーニングで利用するためには、下記のような各種フレームワークを導入する必要があります。

フレームワークの導入に関しては、今後の記事で紹介していきたいと思います。

まとめ

  • ディープラーニングするにはGPUコンピューティングによる強力な計算リソースが必要
  • IDCFクラウドなら、GPU「NVIDIA Tesla M40」搭載の仮想マシンを利用可能
  • CUDAのインストール・フレームワークの導入だけですぐ使える

IDCFクラウド「GPU BOOSTタイプ Tesla M40」のパワーを、ぜひ体験してみてください!

AerospikeをIDCFクラウドで動かすとこんなに良い件

IDCFクラウド クラウド Aerospike

こんにちは、エバンジェリストの藤城(@tafujish)です。

以前にAerospikeのMeetupで登壇させてもらったときに、ブログ書く書く言って長らく書けていなかったのですが、金杉がお試し記事を書いてくれました。

blog.idcf.jp

Aerospikeって何という方はそちらを読んでいただき、ここではAerospikeをIDCFクラウド上で使うのがなぜ適しているのかやベストプラクティスを紹介したいと思います。

なぜ、AerospikeをIDCFクラウド上で動かすのか

1) オールフラッシュストレージ

Aerospikeのデータの格納方法として、超高速にトランザクション処理できるがデータは揮発な「インメモリ」と、データをディスクに格納することで不揮発な「パーシステンス」の両方が利用できます。
その一方で、そもそもAerospikeは高速なトランザクションが得意で、なおかつSSDに最適化されていますので「パーシステンス」でも十分高速です。

IDCFクラウドは、オールフラッシュストレージを採用していますので、ディスクI/Oとしても高速です。そのため、「パーシステンス」で利用したとしても、高速な処理かつデータは不揮発で利用可能です。

2) 高速なCPU/メモリ

Aerospikeの処理にはディスクI/OだけでなくCPUとメモリがもちろん使用されます。Aerospikeの特徴として、スケールアップすることでAerospikeの処理性能を引き上げることができます。

もちろんIDCFクラウドはCPUとメモリの処理速度としても高速です。高性能な仮想化ハイパーバイザーとリソースの最適配置により高性能かつ安定した性能を提供していますので、Aerospikeの高性能を活かすことが可能です。

3) 高帯域の内部ネットワーク

ディスクI/O、CPU、メモリが高速になってくると、ボトルネックがネットワーク帯域になってきます。実際にAerpspikeをオンプレミスで利用しているユーザーの話でも1GbpsのNICがボトルネックになるという話がありました。

IDCFクラウドでは、通常の仮想マシンであれば2Gbps、専有タイプの仮想マシン(3XL128や5XL128)であれば5GbpsのNIC帯域が利用できネットワークボトルネックを回避可能です。

4) マルチキャスト対応

Aerospikeの特徴のひとつとして自律的な動作があります。Aerospikeの各ノードが自動構成されクラスタが組まれ、故障時の切り離しや、クラスタへ戻したときのデータ再配置も自動で行われます。通常、この各ノード間のやりとりはマルチキャスト通信が利用されています。

IDCFクラウドのネットワークでは、マルチキャスト通信が利用可能です。そのためAerospikeのクラスタは、ノードを起動するだけで、自動でクラスタが構築されスケールアウトしていくことが可能なため、簡単に運用することができます。

Aerospike on IDCFクラウドのベストプラクティス

それでは、実際にIDCFクラウド上でAerospikeを動かすときに性能を最大限活用するためのベストプラクティスを紹介します。

●リージョン/ゾーン

高速なディスクI/Oが利用できるため、オールフラッシュストレージを採用しているゾーンを利用してください。
具体的には、東日本リージョンのradian、newtonゾーン。
西日本リージョンのaugusta、monsteraゾーン。
またはこれらより新しいゾーンでオールフラッシュが利用可能です。これらのゾーン上で、仮想マシンを作成すると、そのストレージは特別な操作不要ですべてフラッシュとなります。

最新の対応状況は次のページで確認できます。
https://www.idcf.jp/cloud/spec/region_zone.html

同じゾーン内でAerospikeの仮想マシンを作成すると、同じネットワークに属しマルチキャストにより自動でクラスタが構成されます。

●ネットワークインターフェース

通常、仮想マシンを作成するだけで、高いパケット処理性能・高帯域なNICが提供されます。
RSSに対応しているためRPS/RFSの設定も不要ですのでそのままお使いください。

ただし、ISOからOSをインストールした場合は、その限りではないのでご注意ください。一応、確認方法ですが、

$ ethtool -i eth0
driver: vmxnet3
~以下、略~

driverがvmxnet3になっていればそのままご利用ください。
もし、e1000となっている場合は、テンプレートをエクスポート/インポートしNICを再設定するかRPS/RFSの設定を入れてください。

●DATAディスクのウォームアップ

作成されたDATAディスクは、シンプロビジョニングで作られただけなので使用領域を事前に確保して、オーバーヘッドを減らしておきます。例えば、次のように構築前にゼロデータでディスク容量一杯まで埋めておきます。

$ sudo dd if=/dev/zero of=/dev/sdb bs=1M
dd: writing `/dev/sdb': デバイスに空き領域がありません
819201+0 records in
819200+0 records out
858993459200 bytes (859 GB) copied, 2078.7 s, 413 MB/s

2つ目のDATAディスクがあれば/dev/sdcといったように、利用するデバイスすべてに実施してください。

●ストレージエンジンの設定

Aerospikeの設定(標準で/etc/aerospike/aerospike.conf )にてストレージエンジンの設定をパーシステンスにする際、大きく2パターンあります。

storage-engine device { 
    file /aero/test.dat 
    filesize 64G 
}

こちらの設定では、ファイルシステム上にAerospikeのデータファイルを置くので取り回しが簡単です。
一方、複数のデバイスを並列に扱うことができ、かつファイルシステムをバイパスすることで性能をスケールさせることができる設定もあります。

storage-engine device { 
    device /dev/sdb 
    device /dev/sdc 
    write-block-size 1024K 
}

IDCFクラウドでは、ストレージの種類がひとつだけなので、shadow device(device /dev/sdb /dev/sdcと一行で書く)として階層を設ける必要はありません。接続されているデバイス(DATAディスク)を行を分けて書いてください。

インメモリとパーシステンスのベンチマーク

最後にベンチマークをして、インメモリ(揮発)とパーシステンス(不揮発)の性能差を確認しましょう。

Aerospikeのサーバーは、IDCFクラウドのnewtonゾーン(オールフラッシュ)にて、Standard.X16(4コア/16GBmem)のCentOS6.7にて構築。サーバーとは別のマシンからベンチマークを実行。ベンチマークはAerospikeのCクライアント標準のものを利用し、次のとおり実行しています。結果はAMC上のスループットの値です。

・./benchmarks -h <IP Address> -k 4000000 -o S:2048 -w RU,50 -z 64

Aerospikeサーバーを1台のシングル構成と、3台でクラスタ構成でのベンチマーク結果が次の通りです。

f:id:tafujish:20161116210720p:plain

もちろんの結果ですが、パーシステンスよりインメモリの方がより高速な結果でした。ただ、ここで言いたいのは、インメモリとパーシステンスとの性能差が小さいことです。オールフラッシュが活き、パーシステンスでも十分に高速なので、データが消えるインメモリをわざわざ使わなくても良いのではないでしょうか。

一点補足しておくと、シングル構成と3ノードクラスタ構成で、スコアにほぼ差が出ていないですが、クラスタ構成によりデータレプリケーションが生じるのでその分のオーバーヘッドがあるため台数分の性能になっていません。4台以上にノードを増設していくと、スコアもどんどん上がっていきます。このあたりのスケール性能は、次のAerospikeのMeetupで話させていただいた通りです。

www.slideshare.net

まとめ

Aerospikeはその高性能かつ簡単にスケールできることがメリットのNoSQL DBですが、IDCFクラウドの構成や性能と相性がよいです。また、IDCFクラウドのオールフラッシュストレージの基盤を活用できるのでパーシステンスでの高性能に利用することが可能です。
Aerospikeの事例紹介やEnterprise版の紹介なども可能ですので、これからAerospikeを検討するという場合も、IDCFまでお問い合わせください

Copyright © IDC Frontier Inc.