Quantcast
Channel: idcfクラウド - IDCF テックブログ
Viewing all 122 articles
Browse latest View live

vagrant-cloudstack用 CentOS 6.5 テンプレート公開

$
0
0

こんにちは、梶川です。

先日公開された「Vagrantを使ってCloudStack上の環境構築をしてみよう」はご覧いただけましたか?前回の記事では、Vagrantを使ってIDCFクラウド上の仮想マシンを作る手順をご紹介していますが、記事で利用しているテンプレートは「Ubuntu Server 12.04 LTS」でのご紹介でした。

これを見てCentOSのテンプレートを使って試された方もいるかもしれませんが、CentOSの場合sudo(vagrnatはsudoを使う)のデフォルト設定が「Defaults requiretty」となっているため、ttyを持たないsshによるコマンド実行などができません。

そこで今回vagrantからの利用に適した、CentOS6.5のテンプレートを公開いたします。通常のCentOS6.5からの変更点としては、vagrantユーザーの追加、vagrantユーザーへのssh公開鍵の設定(通常通りrootへも設定されます。)、vagrantユーザーのsudo設定(!requirettyとNOPASSWD: ALL)が変わっています。

Vagrantfile

こちらのテンプレートに合わせたVagrantfileも公開していますのでご利用ください。

※ vagrant-1.4.3 + vagrant-cloudstack-0.2.0 にて確認しています。(display_name,groupの指定は0.2.0以降でないと指定できませんのでご注意ください。)

<strong>VAGRANTFILE_API_VERSION = "2"

    Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
      config.vm.provider :cloudstack do |cloudstack, override|
        override.vm.box = "dummy"
        override.vm.box_url = "https://github.com/klarna/vagrant-cloudstack/raw/master/dummy.box"

        cloudstack.instance_ready_timeout = 1800

        cloudstack.scheme = "https"
        cloudstack.host = "api.noahcloud.jp"
        cloudstack.path = "/portal/client/api"

        cloudstack.api_key = "<span style="color:red; font-weight:normal;">YOUR API KEY</span>"
        cloudstack.secret_key = "<span style="color:red; font-weight:normal;">YOUR SECRET KEY</span>"

        # Zone 1=jp-east-t1v(Tokyo), 2=jp-east-f2v(Shirakawa)
        cloudstack.zone_id = "1"
        # TemplateID 6204=[LATEST][Vagrant Box] CentOS6.5 64-bit for vagrant-cloudstack
        cloudstack.template_id = "6204"
        # ServiceOfferings XS=24,S2=30,S4=22,M4=21,M8=20,L4=31,L8=18,L16=17,L32=16,XL12=26,XL16=15,XL32=52
        cloudstack.service_offering_id = "30"
        cloudstack.keypair = "<span style="color:red; font-weight:normal;">YOUR SSH KEY</span>"

        cloudstack.pf_ip_address_id = "<span style="color:red; font-weight:normal;">IP ADDRESS ID</span>"
        cloudstack.pf_public_port = "22"
        cloudstack.pf_private_port = "22"

        cloudstack.display_name = "<span style="color:red; font-weight:normal;">DISPLAY NAME</span>"
        cloudstack.group = "<span style="color:red; font-weight:normal;">GROUP NAME</span>"

    #    override.ssh.username = "vagrant"
        override.ssh.private_key_path = "<span style="color:red; font-weight:normal;">~/.ssh/id_rsa</span>"
    #    override.ssh.port = "22"
      end
    end</strong>

赤字の部分は必ず環境に合わせて設定する必要があります。確認方法は下記を参照してください。一部前回の内容とかぶりますが、GUI上での確認する方法を載せておきます。

cloudstack.api_key
APIキーの確認
cloudstack.secret_key
API秘密鍵の確認
cloudstack.keypair
仮想マシンに登録する公開鍵を指定
cloudstack.pf_ip_address_id
cloudstack.display_name
仮想マシン表示名の指定(不要であればコメントアウト)
cloudstack.group
仮想マシングループ名の指定(不要であればコメントアウト)
override.ssh.private_key_path
cloudstack.keypairで指定したSSH公開鍵と対になるSSH秘密鍵を指定

その他の部分はデフォルトでも起動はできますが、必要に応じて設定してください。

cloudstack.zone_id
仮想マシンを作成するゾーンを指定。コメントにありますが、1=東京, 2=白河となります。
cloudstack.template_id
作成する仮想マシンに利用するテンプレートの指定になります。コメントにもありますが、今回提供のvagrant対応CentOS6.5のテンプレートのIDは6204となります。
cloudstack.service_offering_id
仮想マシンタイプの指定。課金に直結する部分となります。目的のタイプを選択してください。実際の仮想マシンタイプとID番号はコメントに記載してありますが「XS=24,S2=30,S4=22,M4=21,M8=20,L4=31,L8=18,L16=17,L32=16,XL12=26,XL16=15,XL32=52」となります。
cloudstack.pf_public_port
cloudstack.pf_private_port
ポートフォワーディングの設定
override.ssh.port
sshする際の接続先ポートを指定。cloudstack.pf_public_portでポート番号を変更している場合などは、合わせて変更してください。

これでUbuntu,CentOSどちらもvagrant-cloudstackから利用できるようになりました。vagrantを使って楽々IDCFクラウドを利用しましょう!

vagrant-cloudstackのおさらい

基本的には前回説明していますが、以下にvagrant-cloudstackを利用してIDCFクラウドで仮想マシンを起動するまでの流れを説明します。

Vagrantのインストール

まずは自分の環境にVagrantをインストールしましょう。

DOWNLOAD VAGRANT

<strong>$ vagrant -v
    Vagrant 1.4.3

    $</strong>

vagrant-cloudstackのインストール

<strong>$ vagrant plugin install vagrant-cloudstack
    Installing the 'vagrant-cloudstack' plugin. This can take a few minutes...
    <span style="color:green; font-weight:normal;">Installed the plugin 'vagrant-cloudstack (0.2.0)'!</span>

    $ vagrant plugin list
    vagrant-cloudstack (0.2.0)

    $</strong>

作業ディレクトリとVagrantfileを準備

<strong>$ mkdir idcf-cloud
    $ cd idcf-cloud
    $ vi Vagrantfile  <span style="color:red; font-weight:normal;">&lt;=上記で説明したVagrnatfileを用意</span>
    $ ls
    Vagrantfile

    $
    </strong>

仮想マシンの起動

<strong>$ vagrant up --provider=cloudstack  <span style="color:red; font-weight:normal;">&lt;=--provider=cloudstackを忘れずに!!</span>
    Bringing machine 'default' up with 'cloudstack' provider...
    <span style="color:gold; font-weight:normal;">[default] Warning! The Cloudstack provider doesn't support any of the Vagrant
    high-level network configurations (`config.vm.network`). They
    will be silently ignored.</span>
    [default] Launching an instance with the following settings...
    [default]  -- Display Name: display_name
    [default]  -- Group: group_name
    [default]  -- Service offering UUID: 30
    [default]  -- Service offering UUID: 30
    [default]  -- Template UUID: 6103
    [default]  -- Zone UUID: 2
    [default]  -- Keypair: your_ssh_key_name
    [default] Waiting for instance to become "ready"...
    [default] Creating a port forwarding rule for this instance ...
    [default]  -- IP address ID: xxxxx
    [default]  -- IP address: xxx.xxx.xxx.xxx
    [default]  -- Public port: 22
    [default]  -- Private port: 22
    [default] Waiting for SSH to become available...
    [default] Machine is booted and ready for use!
    [default] Rsyncing folder: /Users/N1302A005/vagrant/test/ => /vagrant

    $</strong>

仮想マシンへssh

<strong>$ vagrant ssh
    <span style="color:cyan; font-weight:normal;">    ________  ______   ______                 __  _
       /  _/ __ \/ ____/  / ____/________  ____  / /_(_)__  _____
       / // / / / /      / /_  / ___/ __ \/ __ \/ __/ / _ \/ ___/
     _/ // /_/ / /___   / __/ / /  / /_/ / / / / /_/ /  __/ /
    /___/_____/\____/  /_/   /_/   \____/_/ /_/\__/_/\___/_/</span>

    [vagrant@i-xxxx-xxxxx-VM ~]$
    </strong>

不要になったら削除

<strong>$ vagrant destroy
    Are you sure you want to destroy the 'default' VM? [y/N] y
    [default] Deleting the port forwarding rule ...
    [default] Terminating the instance...
    [default] Waiting for instance to be deleted
    [default] Waiting for instance to be deleted
    [default] Waiting for instance to be deleted
    [default] Waiting for instance to be deleted
    [default] Waiting for instance to be deleted
    [default] Waiting for instance to be deleted
    [default] Waiting for instance to be deleted
    [default] Waiting for instance to be deleted
    [default] Waiting for instance to be deleted
    [default] Waiting for instance to be deleted

    $</strong>

それでは、VagrantでIDCFクラウドをお楽しみください。

<連載記事>


新しくなったIDCFクラウドの性能と注意点

$
0
0

久しぶりの登場です、ソリューションアーキテクトの藤城(@tafujish)でございます。
遂にIDCFクラウドがリリースされました。新しくなった一番の特長としては、クラウドコンソールの操作がよりわかりやすく、さらにパワフルになったことです。併せて料金も魅力的な金額になっていると思います。

また、これまで通り品質と性能にはこだわって作っています。安くなっていますしどんどんベンチマークしていただきたいのですが、ツールによってはスコアが悪化してしまう可能性があります。そこで、今回はセルフクラウドの環境とIDCFクラウドの環境での性能を比較したいと思います。

ちなみに、10月15日にリリースした新しいクラウドは「IDCFクラウド」、これまでのクラウドは「セルフクラウド」です。IDCFクラウドとセルフクラウドは、プラットフォームが異なりますのでお間違えなく!

UnixBenchではそのまま比較しない

これまでUnixBenchを用いたベンチマークを紹介してきましたが、そのまま実行するとIDCFクラウドの方がスコアが低くなります。

セルフクラウドのXL32(8vCPU @2.4GHz、32GBmem)とIDCFクラウドのStandard XL32(8vCPU @2.4GHz、32GBmem)は、スペック上は同等です。提供している物理CPUは、セルフクラウドはSandyBrigeでIDCFクラウドはIvyBridgeのXeonなのでクロックあたりの性能も大差は出ません。それなのに、IDCFクラウドの方がスコアが悪いのです。これは不具合によるもので、IDCFクラウドの開発段階での性能比較に際し、UnixBenchのスコアが低下することを発見しました。

ハードウェア、ソフトウェア両面から調査し、原因とその影響範囲の特定に約1か月を要しました。コードレベルまで調査し、特定の機能が有効になっている環境で、特定の命令を大量に繰り返し実行したとき、この不具合が発生することがわかり、併せて現実的なワークロードには影響が出ないことが確認できました。しかし、ベンチマークのパフォーマンス値に影響のある状況のためIDCFが責任をもって修正にあたっています。修正完了するまでは、ベンチマークの際はご注意ください。以降はこの事象を回避してベンチマークをする方法をご紹介します。

なお、この不具合が生じた後、性能劣化は継続し続けます。この状態を復旧させるには、仮想マシンを停止し、ポータルから仮想マシンを起動することで復旧可能です。OS上で再起動するだけでは復旧しませんのでご注意ください。

1) execlテストを除外しUnixBenchを実行

この不具合の影響を受けることが確認できているのはUnixBenchのExecl Throughputテストのみです。そのため、Execl Throughputを除外してUnixBenchを実行します。

●UnixBench通常実行の場合
    # <strong>./Run</strong>

    ●Execl Throughputテストを外し実行する場合
    # <strong>./Run dhry2reg whetstone-double fstime fsbuffer fsdisk pipe context1 spawn shell1 shell8 syscall</strong>

Execl Throughputテストを外し実行したスコアが次の通りです。

セルフクラウドのXL32(8vCPU @2.4GHz、32GBmem)とIDCFクラウドのStandard XL32(8vCPU @2.4GHz、32GBmem)では、スペック通りほぼ同等のスコアとなりました。セルフクラウドのM4(2vCPU @1.6GHz、4GBmem)とIDCFクラウドのHighCPU M4(2vCPU @2.6GHz、4GBmem)では、クロックが向上している分スコアも向上しました。

2) ASLRを無効化して

今回の不具合のトリガーの一つに、ASLR(Address Space Layout Randomization)が有効になっていることが挙げられます。これを無効にすると今回の不具合の影響は受けないため、正常なベンチマークスコアが得られます。ただし、ASLRはバッファオーバーフロー攻撃対策のセキュリティ機能のため、通常時は有効にすることを推奨します。ベンチマークのときのみ無効化し、完了後には有効化すると良いです。ASLRを無効化するには以下のように実行します。

●無効化するとき(不具合を回避するとき)
    # <strong>sysctl -w kernel.randomize_va_space=0</strong>

    ●有効化するとき(通常時に戻すとき)
    # <strong>sysctl -w kernel.randomize_va_space=1</strong>

無効化した状態で、ベンチマークを実施したスコアが次の通りです。

1)の結果と同じ傾向が得られました。

3) 他のベンチマークツールで比べる

先述の通り、現時点で不具合の影響が出るベンチマークツールはUnixBenchのみです。そのため、UnixBench以外の他のベンチマークツールで比較すると良いです。ここでは、MySQLに対してSysBenchのOLTPで比較したときの例を紹介します。

UnixBenchではないと不具合の影響を受けないことがわかります。

まとめ

現在、一部のベンチマークツールにて性能劣化する不具合が確認されており、根本解決に向け鋭意対応中です。しかし、通常のワークロードでは今回の不具合の影響は受けませんので安心してご利用いただけます。UnixBenchをされる場合は、Execl Throughputテストを外すか、ASLRを一時的に無効化しベンチマークいただければ正しい値が取得できます。

以上のとおりややこしいですが、性能とコストパフォーマンスにはこだわってクラウドを作っていますので是非ベンチマークしていただきたいと思っています。 まずは1万円分のクーポンを使ってお試しください。※2014年11月14日(金)17時まで

上記ベンチマークの値はCentOS6.5にて計測した値です。

<関連記事>

IDCFクラウド APIを利用した仮想マシンの作成からSSH接続まで

$
0
0

こんにちは。IDCフロンティア UX開発部の上野です。ご無沙汰しております。

さて前回の藤城の投稿に引き続いて今回もIDCFクラウドについての投稿となります。 藤城の投稿ではIDCFクラウドの一番の特長として、「クラウドコンソールの操作がよりわかりやすく」が挙げられているのですが、今回はコマンドラインツールでのIDCFクラウドの操作方法について記載させてもらいます。 なんかすいませんm()m

さて気を取り直して、今回やることとしては以下となります。

  • SSH-Keyのアップロード
  • 仮想マシンの作成
  • SSH-Keyの設定

これを行うことでコマンドラインのみで仮想マシンを作成してSSH接続できるようになるので、コマンドラインのみで環境構築する第一歩になるかと思います。

環境情報

以下手順を確認した環境情報となります。

コマンドラインツールはPythonですのでPython環境が必要になります。

  • OS: Mac OSX 10.9.5
  • Python: 2.7.5

前提条件

前提条件は以下となります。

  • IDCFクラウドのアカウントを持っていること
  • Homebrewがインストール済みであること

2014/11/14まで1万円のクーポンが発行されているらしいのでアカウント登録するなら今かと^^

Step1:コマンドラインツールのインストール

Step1-1:gitのインストール

コマンドラインツールはGitHub上にありますので、インストールにはgitコマンドが必要になります。gitコマンドをインストール済みの方は本手順は不要となります。


$ sudo brew install git

Step1-2:pipのインストール

Pythonのパッケージ管理システムであるpipをインストールします。既にインストール済みの方は本手順は不要となります。


$ curl -kL https://raw.github.com/saghul/pythonz/master/pythonz-install | bash
$ sudo easy_install pip

Step1-3:コマンドラインツールのインストール

さてこれでコマンドラインツールをインストールする準備が整いました。 インストールは簡単で以下のコマンドを実行することでインストールできます。


$ sudo pip install git+https://github.com/idcf/cloudstack-api

Step2: API-Key/Secret-Keyの取得

コマンドラインツールを利用するためにはアカウントに紐づいたAPI-KeyとSecret-Keyが必要になります。

Step2-1: IDCFクラウドコンソールにログイン

まずはクラウドコンソールにログインします。

webconsle_signin

Step2-2: API画面に遷移

サイドメニューのAPIタブをクリックしてAPI画面に遷移します。

webconsle_home

Step2-3: エンドポイント/API-Key/Secret-Keyの記録

API画面に表示されている以下の項目を記録しておきます。これらの情報はコマンドラインツールで利用する値となります。

  • エンドポイント
  • API Key
  • Secret Key
webconsle_api-key

Step3: コマンドラインツールの設定


Step3-1: 環境設定

Step2で取得したコマンドラインツールの設定ファイル(~/.idcfrc)に設定します。


~/.idcfrc
[account]
host=https://xxxx.xxxx.xxxx.xxxx/client/api
api_key=xxxxxxxxxxxFBinrxjObdNx3LdF9KAM3JqRtAFRkYDrnKUiRBhrInpUuQN1aJOca4JOCpm2TNAr1Cob6yAg
secret_key=xxxxxxKyx5jjElMUsQSepOjazWUQLmJZkC1LFPEBN0t54FJqIFu2BNY32HnX5g5ohjOKVEBSUy6rhIVbOrgErXQ

hostにエンドポイント、api_keyにAPI Key、secret_keyにSecret Keyを設定します。

Step3-2: 導通確認

設定が正常に行われているかを以下のコマンドで確認します。Zone情報を取得するコマンドとなります。


$ cloudstack-api listZones -t
+-----------------+---------------+--------------------------------------+---------------------+-------+-------------+-----------------------+------+--------------------------------------+
| allocationstate |  dhcpprovider |                  id                  | localstorageenabled |  name | networktype | securitygroupsenabled | tags |              zonetoken               |
+-----------------+---------------+--------------------------------------+---------------------+-------+-------------+-----------------------+------+--------------------------------------+
| Enabled         | VirtualRouter | a117e75f-xxxx-4074-806d-889c61261394 | False               | tesla | Advanced    | False                 | []   | xxxxxxxx-a3c5-3538-8a2a-71d93a788ab5 |
+-----------------+---------------+--------------------------------------+---------------------+-------+-------------+-----------------------+------+--------------------------------------+
$

上記のようにZone情報が表示されれば正常に設定が行われています。

Step4: SSH-Keyのアップロード

Step4-1: SSH-Keyの作成

SSH-Keyを作成します。まだない方は以下のコマンドで作成してください。


$ ssh-keygen -t rsa

Step4-2: SSH-Keyのアップロード

以下のコマンドでSSH-KeyをIDCFクラウド上にアップロードすることができます。 $ cloudstack-api registerSSHKeyPair --name idcf-test --publickey "$(cat ~/.ssh/id_rsa.pub)" -t +-----------------------------------------------------------------------------------------+ | keypair | +-----------------------------------------------------------------------------------------+ | {'name': 'idcf-test', 'fingerprint': 'a9:bd:d9:d9:f1:75:54:01:20:75:d7:d1:bf:1a:d7:77'} | +-----------------------------------------------------------------------------------------+

本当に登録されているかの確認は以下のコマンドとなります。


$ cloudstack-api listSSHKeyPairs -t
+-------------------------------------------------+-----------+
|                   fingerprint                   |    name   |
+-------------------------------------------------+-----------+
| a9:bd:d9:d9:f1:75:54:01:20:75:d7:d1:bf:1a:d7:77 | idcf-test |
+-------------------------------------------------+-----------+

登録されていますね。

Step5: 仮想マシンの作成

Step5-1: 仮想マシンタイプの取得

まずは作りたい仮想マシンタイプを取得します。以下のコマンドで取得することができます。


$ cloudstack-api listServiceOfferings -t id,displaytext
+--------------------------------------+------------------------------------+
|                  id                  |            displaytext             |
+--------------------------------------+------------------------------------+
| 12e39b73-3ce6-4e57-9036-3dac0c2b2b06 | highmem.M16( 2CPU / 16GB RAM )     |
| 354c62e6-b99b-42f2-b5c7-e741f1085422 | standard.XL32( 8CPU / 32 GB RAM )  |
| 435c1aab-e796-42c7-9320-22ebdc8f50aa | highcpu.L8( 4CPU / 8GB RAM )       |
| 55621f17-4d38-457c-ba34-e6199701b67b | standard.S4( 1CPU / 4GB RAM )      |
| 6a99ff4c-1a24-4aa6-b4cc-600220987ed0 | standard.L16( 4CPU / 16GB RAM )    |
| 6fda5e0c-e64d-46ea-893d-7e2ac9e128e7 | highcpu.XL16 ( 8CPU / 16GB RAM )   |
| 7ae143a6-5662-4f1d-bc4c-10defa775bcb | standard.M8( 2CPU / 8GB RAM )      |
| 7c548831-427b-437c-9c8b-80dde8031303 | highcpu.2XL32( 16 CPU / 32GB RAM ) |
| 8cf15770-c3c8-4efc-8ae5-b8327790db76 | highcpu.M4( 2CPU / 4GB RAM )       |
| d1aac6d2-bb47-4106-90d0-6a73ac3ae78e | light.S2( 1CPU / 2GB RAM )         |
| d59817bc-ed79-4083-8b71-51b26c76d311 | highmem.L32( 4CPU / 32GB RAM )     |
| e01a9f32-55c4-4c0d-9b7c-d49a3ccfd3f6 | light.S1( 1CPU / 1GB RAM )         |
| ee5ee568-76b2-46ad-9221-c695e6f2149d | highmem.XL64( 8CPU / 64GB RAM )    |
+--------------------------------------+------------------------------------+

作りたい仮想マシンタイプのidを記録しておいてください。今回は「light.S2」で作成しようと思います。

Step5-2: テンプレート情報の取得

作りたい仮想マシンのテンプレート情報を取得します。以下のコマンドで取得することができます。


$ cloudstack-api listTemplates --templatefilter executable -t id,ostypename | wc -l
      34
$ # 数が多いので抜粋して表示させています。
$ cloudstack-api listTemplates --templatefilter executable -t id,ostypename | more
+--------------------------------------+---------------------------------------+
|                  id                  |               ostypename              |
+--------------------------------------+---------------------------------------+

| b2d2a4fa-d694-444b-b961-0a0f9d7fe0f3 | Ubuntu 12.04 (64-bit) | +--------------------------------------+---------------------------------------+

今回は「Ubuntu 12.04 (64-bit)」を利用しようと思います。

Step5-3: 仮想マシンの作成

さてようやく仮想マシンの作成の準備が整いました!以下のコマンドで仮想マシンを作成することができます。


$ cloudstack-api deployVirtualMachine --serviceofferingid d1aac6d2-bb47-4106-90d0-6a73ac3ae78e --templateid b2d2a4fa-d694-444b-b961-0a0f9d7fe0f3 --zoneid a117e75f-xxxx-4074-806d-889c61261394 --group idcf-test --keypair idcf-test --displayname  idcf-dev01  --name idcf-dev01

上記のコマンドで「idcf-test」というグループの「idcf-dev01」という仮想マシンが作成されます。 --zoneidには正常性確認時のZone IDを指定してください。

さて少し経ったあとに以下のコマンドで仮想マシンが作成されているかを確認します。


$ cloudstack-api listVirtualMachines -t id,displayname,created,state
+--------------------------------------+----------------+--------------------------+---------+
|                  id                  |  displayname   |         created          |  state  |
+--------------------------------------+----------------+--------------------------+---------+
| f4894a29-fe02-4021-9e17-b35795b97b33 | idcf-dev01     | 2014-10-24T13:46:32+0900 | Running |
+--------------------------------------+----------------+--------------------------+---------+

Running状態で作成されていることがわかると思います。

Step6: ルーティング設定

このままでは仮想マシンまでのルーティングが設定されていないのでルーティング設定する必要があります。

Step6-1: パブリックIPアドレスの確認

以下のコマンドで利用可能なパブリックIPアドレスを確認します。

$ cloudstack-api listPublicIpAddresses -t id,ipaddress +--------------------------------------+-----------------+ | id | ipaddress | +--------------------------------------+-----------------+ | 2de1ed89-62b5-4723-abc6-4e4e5e700507 | xxx.xxx.xxx.xxx | +--------------------------------------+-----------------+

これがインターネット環境から接続可能なアドレスとなります。

Step6-2: ポートフォワーディングの設定

パブリックIPアドレスに作成した仮想マシンへのポートフォワーディングルールを設定します。


$ cloudstack-api createPortForwardingRule --ipaddressid 2de1ed89-62b5-4723-abc6-4e4e5e700507 --privateport 22 --protocol TCP --publicport 22 --virtualmachineid f4894a29-fe02-4021-9e17-b35795b97b33 -t
+--------------------------------------+--------------------------------------+
|                  id                  |                jobid                 |
+--------------------------------------+--------------------------------------+
| 93235621-839c-46fb-87f1-6a2d925b1f9b | e871031f-4603-45c2-81ba-940099a2e10e |
+--------------------------------------+--------------------------------------+

しばらく経った後に以下のコマンドで設定されているかを確認します。


$ cloudstack-api listPortForwardingRules -t ipaddressid,publicport,state,virtualmachinedisplayname
+--------------------------------------+------------+--------+---------------------------+
|             ipaddressid              | publicport | state  | virtualmachinedisplayname |
+--------------------------------------+------------+--------+---------------------------+
| 2de1ed89-62b5-4723-abc6-4e4e5e700507 | 22         | Active | idcf-dev01                |
+--------------------------------------+------------+--------+---------------------------+

Activeになっていることがわかるかと思います。

仮想マシンにSSH接続

最後にローカル環境から仮想マシンにログインしてみます。


$ ssh root@xxx.xxx.xxx.xxx
Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-33-generic x86_64)
  • Documentation: https://help.ubuntu.com/

root@idcf-dev01:~#

接続できました!

おわりに

いかがでしたでしょうか。結構手順的には多かったと思いますが、コマンドラインツールだけでSSH接続できることを実感して頂けたかなと思います。

API Keyの取得などは別として。

次回は環境の自動構築までをコマンドラインツールでできればいいなと思ってますので、ご興味があればまたご覧ください。 それでは!

<関連記事>

Mackerelブログリレー『第1回 新人がIDCFクラウドでMackerelを使ってみた』

$
0
0

こんにちは!ビジネス開発本部の栗林です。

普段は営業のお仕事をしています。

今回は、IDCFクラウド用に特別プランで提供されているMackerelについて、リレー形式で5回に分けて記事を書いていきます。

 

第1回. Mackerelを登録してみた

第2回. Mackerelにホスト登録してみた

第3回. Mackerelのプラグインを使ってみる~他ツールとの比較

第4回. Mackerel APIを触ってみる

第5回. MackerelでIDCFクラウドのオートスケール それでは早速、Mackerelを解剖していきましょう!

■Mackerelとは何だろう?

Mackerel(マカレルと読みます。日本語で鯖という意味です)とは、株式会社はてなが提供するクラウドパフォーマンス管理ツールです。機能としては仮想マシンの管理や監視がグラフ形式で表示されるとともに、ロールと呼ばれる概念を使用し複数のサーバーを一括で管理する事ができます。

 

詳細は下記の公式サイトをご覧ください。

株式会社はてな(http://www.hatena.ne.jp/)

Mackerel公式サイト(https://mackerel.io/)

[caption id="attachment_4473" align="aligncenter" width="792" class=""]MackerelIDCフロンティアプラン比較表 IDCフロンティア利用プラン[/caption]

IDCFクラウドの特別プランではホスト数無制限、グラフ表示 1週間を無料でご利用いただけます。∈(゜◎゜ )∋! *IDCフロンティア「国内初!はてなのMackerelがIDCFクラウドで使えます!

 

■Mackerelに登録してみよう

 

それでは早速、IDCFクラウドでMackerelの登録をしてみましょう。

 

登録までのステップは次の通りです。

  1. IDCFクラウドにログイン

  2. 左上部タブ<東日本リージョン>コンピューティング>をクリックするとメニュータブが開く

  3. タブ内の<Mackerel>をクリック

以上でIDCFクラウド側での作業は終了です。

 

東日本リージョン2

つづいて、Mackerelの画面でのサインアップ操作になります。

  1. Mackerelの<サインアップ>をクリック

IDCFクラウドサインアップ

  1. メールアドレスを登録し、<次へ>をクリック

  2. オーガニゼーション名を入力しIDCFクラウド用のチェックを入れ、<作成>をクリック

※オーガニゼーション名がアカウント名になります。オーガニゼーションは複数作成可能です。

オーガニゼーション

以上で登録完了です。

∈(゜◎゜ )∋<非常に簡単です!

 

■Mackerelのアカウント設定を変更しよう

 

言語の設定変更

Mackerelでは言語を日本語/英語から選べます。

  1. Mackerelサービス内の右上の<メールアドレス>をクリック

  2. <Settings>をクリックすると、個人設定ページに移ります。

setting

 

 

  1. 次のページで言語が日本語/英語から選択できますので、日本語を選んでください。

setting

 

 

メンバーの登録

  1. ダッシュボードのオーガニゼーショントップに移動

  2. メンバーをクリック

  3. 招待するをクリック

招待

  1. メールアドレスで登録したいメンバーに招待を行う

  2. メンバーに招待メールが届く メンバー2

Mackerelのサイトは直感的な操作ができるUIになっており、わかりやすいですね。

IDCFクラウドも直感的UIを目指していますので、見習っていきたいです。

 

第1回. Mackerelを登録してみたはここまでとなります。

近日、「第2回. 新人がIDCFクラウドでMackerelにホスト登録してみた」をアップしますので、ご期待ください。

Mackerelブログリレー『第2回 新人がMackerelにホスト登録してみた』

$
0
0

こんにちは!栗林です。

前回に引き続き、Mackerelブログリレーの第2回です!

 #前回からだいぶお待たせしてしまいました。。。

 

今回のテーマは『Mackerelにホスト登録してみた』です。

IDCFクラウドをご利用のお客様はMackerelを特別プランでご利用いただけます。

 

第1回. Mackerelを登録してみた

2. Mackerelにホストを登録してみた

第3回. Mackerelのプラグインを使ってみる~他ツールとの比較

第4回. Mackerel APIを触ってみる~IO性能比較

第5回. MackerelでIDCFクラウドのオートスケール

それでは早速、Mackerelを解剖していきましょう!

 

 

■Mackerelの用語を知ろう!

まずはMackerelを始める上での基礎用語を覚えましょう。

 

  • オーガニゼーション

Mackerelを利用する組織の単位です。例えば会社やグループ、個人を指します。

  • ホスト

Mackerelで監視をするサーバーです。このホストにMackerelエージェントをインストールをして監視・管理を行います。

  • サービス

ホスト群をまとめるグループです。

関連したホストを分かりやすく、まとめて管理することができます。

  • ロール

サービスの中にいるホストの役割です。

例えば「WEBサーバー」や「DBサーバー」などと各役割を設定することで纏めて可視化する事ができます。

 

もっと詳しく知りたい方は、Mackerelの用語集ページをご活用ください。

http://help-ja.mackerel.io/entry/glossary

 

■スタートガイドを活用しよう

Mackerelのメニュー下部に「スタートガイド」があります。

今回はスタートガイドに従って、「ホストにロールを紐づけるまで」を記事にしました。

 #このスタートガイドは、作業が終わった箇所にチェックを付けて判別してくれます。

 #Mackerelのアカウント登録についてはMackerelを登録してみたをご覧ください。

スタートガイド

■ホストの登録をしてみよう

まずは対象のホストの登録を行います。

1.メニューのスタートガイドをクリックすると、登録までの流れが表示されます。

2.「2.新規ホストを登録する」の右側にある「新規ホストの登録」をクリックします。

3.「新規ホストの登録」の画面に変わります。

 

新規ホストの登録では、3種類のインストール方法が表示されます。

  • RPMパッケージをインストールする (Redhat,CentOSなど)
  • debパッケージをインストールする (Debianなど)
  • 実効形式ファイルを設置する

登録したいホストのOSに適したインストール方法を選んでください。

 

 #今回は仮想マシンのOSにCentOSを選択したため、RPMパッケージをインストールするを選択します。

この際、コマンドの右側にあるアイコンをクリックするとコマンドをクリップボードにコピーできます。

∈(゜◎゜ )∋<非常に便利です!

新規ホスト登録 4.監視したい仮想マシンにSSH接続し、表示されるコマンドを順番に実行します。

5.Start時に[OK]と出れば成功です。これでホストの登録ができました。 SSH

コマンドを実行し、成功した図

 #コピーぜすに、手打ちで試したら100%失敗しました・・・ <*)) >=<

 

■サービスをつくろう

1.メニューのスタートガイドの「3.サービスをつくってみましょう」の右側にある「新規サービスを作成」をクリックします。

2.「新しいサービスを作成」の画面に変わります。サービス作成 3.サービスの名前を記入しましょう。サービスに関するメモを記入する事もできます。

新しいサービス作成

以上でサービスの作成は終了です。

 

■ロールをつくろう

1.メニューのスタートガイドの「4.ロールをつくる」の右側にある「新規ロールを作成」をクリックします。

2.「新規ロールを作成する」の画面に変わります。

ロール作成

3.ロールの名前を記入しましょう。サービスと同様にメモを記入する事もできます。

ロール作成2

以上でロールの作成は終了です。

 

■ホストにロールを紐付けよう

1.メニューのスタートガイドの「5.ホストにロールを紐付ける」の右側にある「ホストにロールを紐付ける」をクリックします。

ホストーロールひも付

2.「Hosts」の画面に変わります。

3.「ロールを設定」をクリックするとロールの選択画面が現れます。

hosts

ひとつのホストに複数のロールを登録する事ができます。

 

以上でロールの紐付けは終了です。

 

おめでとうございます!

以上でひと通り設定が完了しました。

メニューの「Hosts」から各種設定が閲覧できます。

 

グラフ

 

以下は私が試してみた結果です。

■モニタリング結果を見てみよう

次の画面はコマンドのtopを打ってリソースに変化が出たか試している所です。

top結果

試しにtopコマンドを打ってみました。

topグラフ

少しだけdiskのグラフに変化が出ました!∈(゜◎゜ )∋

みなさまもぜひ、お試しください!

 

 

「第2回. Mackerelにホストを登録してみた」はここまでとなります。

 

次回は「第3回. Mackerelのプラグインを使ってみる~他ツールとの比較」をアップしますので、ご期待ください。

 

<関連記事>

Mackerelブログリレー『第1回 新人がIDCFクラウドでMackerelを使ってみた』

 

IDCFクラウド対応CoreOSテンプレートをリリース

$
0
0

CoreOS

最近、Hypervisor型とは異なる仮想化技術であるコンテナ化技術をベースとした「Docker」が話題となっています。そして、Dockerを動かすことに特化したLinux Distributionとして「CoreOS」が注目されています。このたび、IDCFクラウドに対応したCoreOSテンプレートをリリースいたしました。

CoreOSテンプレートは、通常のテンプレートと使用方法が異なる部分がいくつかあるため、IDCFクラウド対応の機能説明と合わせて、基本的な使い方を紹介いたします。

1. IDCFクラウド対応CoreOSテンプレートの機能

このたびリリースしたCoreOSテンプレートには、CoreOSをISOイメージからインストールした場合と比べて、以下の機能が追加されています。

  1. VMware Tools (open-vm-tools)がインストールされており、IDCFクラウドのポータル画面からの再起動などに対応
  2. IDCFクラウドの仮想マシン作成時に指定するSSHキーの設定に対応(ただしrootではなく「core」ユーザーのSSHキーとして設定)
  3. CloudStack APIにある「User Data」機能を用いてcloud-config.ymlを投入することで、仮想マシン起動時のCoreOS自動構築に対応
  4. NTPの時刻同期先としてIDCFクラウドで提供しているNTPサーバーを指定
  5. TimezoneをAsia/Tokyoに設定

なお、通常の仮想マシンテンプレートと異なり、パスワードの自動設定および初期化機能には対応していないのでご注意ください。

2. CoreOSテンプレートを使った仮想マシン作成

では、早速CoreOSテンプレートから仮想マシンを作成してみましょう。ここでは、IDCFクラウドのアカウント登録と支払情報の登録が既に完了している前提で説明いたします。

2-1. ポータル画面からのCoreOS仮想マシン作成

  • IDCFクラウドのポータルにログインします。
  • 次に画面上部の「仮想マシン作成」をクリックします。
  • 「イメージ」の項目で「その他」をクリックするとイメージ一覧にCoreOS (stable) 494.4.0 64-bitが表示されるので選択します。 coreos_template
  • 「SSH Key」でSSHログインに使う公開鍵を指定もしくは生成します。生成した場合は表示された秘密鍵を保存します。 SSHkey
  • 仮想マシン名などを適宜指定したあと「確認画面へ」をクリックし、内容に間違いがなければ仮想マシンの作成を実行します。

2-2. 作成した仮想マシンへのSSHログイン

  • ポータル画面左側の「IPアドレス」をクリックし、次にSSH接続に利用するIPアドレスを選択します。
  • 「ファイアウォール」をクリックします。ソースCIDRの欄にある選択肢で「My IP」を指定すると、現在操作をしている端末のパブリックIPが自動的に指定されるので非常に便利です。タイプとして「SSH」を選択して右端のボタンをクリックします。 firewall1
  • 次に「ポートフォーワード」をクリックします。「プライベートポート」を「SSH」と指定し、パブリックポートを「22」と入力、「仮想マシン」では先ほど作成した仮想マシン名を選択します。その後右端のボタンをクリックします。 port
  • SSHクライアントソフトを使い、ここまでの手順で設定したIPアドレスにSSH接続を開始します。この際、ユーザー名は「core」、SSH Keyには仮想マシン作成時に登録した鍵ペアを指定します。

以上でCoreOSにログインできます。なお、管理者権限で操作するにはsudoコマンドを利用します。

 

3. CloudStack User Data機能を使ったCoreOSの自動構築

CoreOSには以下の特徴があります。

  1. Dockerを動かすことに特化しており、非常にイメージサイズ、メモリ消費等が少ない
  2. CoreOS自体にアプリケーションを追加することは原則行わず、RPMなどのパッケージマネージャも存在しない
  3. クラウド(IaaS)上で大量にサーバーを立てることを前提として、OS設定自動化の仕組み(cloud-init)がある

IDCFクラウド対応のCoreOSテンプレートも上記のcloud-initに対応しています。ここでは、cloud-initによる設定自動化の手順を解説します。

3-1. cloud-initとは

CoreOSに搭載されているcloud-init機能とは、OSの起動時に初期設定(ネットワーク設定、ユーザーの作成、サービスの起動など)を自動的に行うための機能です。初期設定したい項目を所定の書式で記述し、cloud-config.ymlとして保存し、OS起動時に読み込ませるようにします。 cloud-config.ymlの読み込み方法(Datasourceといいます)には色々なものがあります。Amazon EC2や当社IDCFクラウドのUser Data機能や、cloud-config.ymlを保存したDiskから読み込ませる等があります。User Data機能を使うと、APIとの組み合わせで大量のCoreOSを自動的に構築できるようになります。

詳細な使い方についてはCoreOSドキュメントサイトの「Using Cloud-Config」や「CloudInit Documentation」に詳細な解説があります。

3-2. CloudStackのUser Data機能を使ったcloud-init

それでは実際にIDCFクラウド(CloudStack)のUser Data機能を使ってCoreOS起動時に初期設定を行うようにしてみましょう。 まず、IDCFクラウドへAPIを実行する環境については、弊社サポートサイトのAPI利用手順や以前のBlog記事「APIを利用した簡単オートスケール」にて解説済みの手順で準備済みである前提とします。

次に、CoreOSに実行させたい初期設定ファイルcloud-config.ymlを作成します。今回の例ではidcfというユーザーの作成、SSH公開鍵の設定、およびDockerサービスを起動するという内容でテストをします。


#cloud-config
users:
  - name: idcf
    groups:
      - sudo
    ssh-authorized-keys:
      - ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDBXkUaxwRYPHjcciI00uO8AB1tgIK7h0KARYY5JS6JlaHaHR/3yx02HbBv5lEPDsz6xDVb7vHOTJpiMXIUUvJ4Z480A6EF0wIwTB0xVvElIR/Az6ys4FkO1A+jo6udevoLob1PO4VwwZjqFY+YTLtkGBbtvrrbfQNJTMagZTf4Z2NNmQ4sHI6b4ge5wE+CD+fCE1wSh9IU+HjWp6wkKaKQXSdvzxFFf5lf0N0UiZHzRyE99vK3tWw9a+jyNMZb067WYPV/aXGB1Doko3v9x0zklKFUx4nJG3iIQ09fQIXQQUMNV8f5FypJubzYu+uvx8/zXQk98Jx4vI9jPVJS6S7d
coreos:
    units:
      - name: docker.service
        command: start

CloudStackのUser Dataについて、いくつか注意点があります。

  • APIに引数として渡すデータはBase64エンコードし、改行を削除した文字列である必要がある
  • cloudstack-apiコマンド等HTTP GETリクエストで送信できるUser DataはBase64エンコード後で2KBまで対応
  • HTTP POSTリクエスト(User Data自体はPOSTのBody部分に記載)を使うと32KBまで対応
  • Base64エンコード前のデータのバイト数が3の倍数ではない場合、正常に認識できない

最後の点があるため、上記の例では改行などを削除して合計546バイトにしています。

APIを実行する端末上で上記の内容のcloud-config.ymlを作成した後、Base64エンコードした文字列を取得します。


$ base64 cloud-config.yml | tr -d "\n" ;echo ""
I2Nsb3VkLWNvbmZpZwp1c2VyczoKICAtIG5hbWU6IGlkY2YKICAgIGdyb3VwczoKICAgICAgLSBzdWRvCiAgICBzc2gtYXV0aG9yaXplZC1rZXlzOgogICAgICAtIHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQURBUUFCQUFBQkFRREJYa1VheHdSWVBIamNjaUkwMHVPOEFCMXRnSUs3aDBLQVJZWTVKUzZKbGFIYUhSLzN5eDAySGJCdjVsRVBEc3o2eERWYjd2SE9USnBpTVhJVVV2SjRaNDgwQTZFRjB3SXdUQjB4VnZFbElSL0F6NnlzNEZrTzFBK2pvNnVkZXZvTG9iMVBPNFZ3d1pqcUZZK1lUTHRrR0JidHZycmJmUU5KVE1hZ1pUZjRaMk5ObVE0c0hJNmI0Z2U1d0UrQ0QrZkNFMXdTaDlJVStIaldwNndrS2FLUVhTZHZ6eEZGZjVsZjBOMFVpWkh6UnlFOTl2SzN0V3c5YStqeU5NWmIwNjdXWVBWL2FYR0IxRG9rbzN2OXgwemtsS0ZVeDRuSkczaUlRMDlmUUlYUVFVTU5WOGY1RnlwSnViell1K3V2eDgvelhRazk4Sng0dkk5alBWSlM2UzdkCmNvcmVvczoKICAgIHVuaXRzOgogICAgICAtIG5hbWU6IGRvY2tlci5zZXJ2aWNlCiAgICAgICAgY29tbWFuZDogc3RhcnQK

上記文字列を使って、先ほど作成した仮想マシンにUser Dataを設定します。


$ cloudstack-api listVirtualMachines -t id,name,group,state
+--------------------------------------+--------+-------+---------+
|                  id                  |  name  | group |  state  |
+--------------------------------------+--------+-------+---------+
| 3583dc29-5860-47aa-bc13-9fbb7ce50d46 | coreos | test  | Running |
+--------------------------------------+--------+-------+---------+
$ cloudstack-api updateVirtualMachine --id 3583dc29-5860-47aa-bc13-9fbb7ce50d46 \
  --userdata I2Nsb3VkLWNvbmZpZwp1c2VyczoKICAtIG5hbWU6IGlkY2YKICAgIGdyb3VwczoKICAgICAgLSBzdWRvCiAgICBzc2gtYXV0aG9yaXplZC1rZXlzOgogICAgICAtIHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQURBUUFCQUFBQkFRREJYa1VheHdSWVBIamNjaUkwMHVPOEFCMXRnSUs3aDBLQVJZWTVKUzZKbGFIYUhSLzN5eDAySGJCdjVsRVBEc3o2eERWYjd2SE9USnBpTVhJVVV2SjRaNDgwQTZFRjB3SXdUQjB4VnZFbElSL0F6NnlzNEZrTzFBK2pvNnVkZXZvTG9iMVBPNFZ3d1pqcUZZK1lUTHRrR0JidHZycmJmUU5KVE1hZ1pUZjRaMk5ObVE0c0hJNmI0Z2U1d0UrQ0QrZkNFMXdTaDlJVStIaldwNndrS2FLUVhTZHZ6eEZGZjVsZjBOMFVpWkh6UnlFOTl2SzN0V3c5YStqeU5NWmIwNjdXWVBWL2FYR0IxRG9rbzN2OXgwemtsS0ZVeDRuSkczaUlRMDlmUUlYUVFVTU5WOGY1RnlwSnViell1K3V2eDgvelhRazk4Sng0dkk5alBWSlM2UzdkCmNvcmVvczoKICAgIHVuaXRzOgogICAgICAtIG5hbWU6IGRvY2tlci5zZXJ2aWNlCiAgICAgICAgY29tbWFuZDogc3RhcnQK
(エラーが表示されないことを確認)

仮想マシンを再起動することで設定を反映させます。


$ sudo cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
core:x:500:500:CoreOS Admin:/home/core:/bin/bash
$ sudo systemctl -al | grep docker
  docker.service                           loaded    inactive    dead      Docker Application Container Engine
  docker.socket                            loaded    active      listening Docker Socket for the API
  early-docker.target                      loaded    inactive    dead Run  Docker containers before main Docker starts up
$ sudo reboot

(CoreOS再起動を実施後、再びSSHログイン)

$ sudo cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
core:x:500:500:CoreOS Admin:/home/core:/bin/bash
idcf:x:1000:1000::/home/idcf:/bin/bash
$ sudo cat /home/idcf/.ssh/authorized_keys
# auto-generated by /usr/bin/update-ssh-keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDBXkUaxwRYPHjcciI00uO8AB1tgIK7h0KARYY5JS6JlaHaHR/3yx02HbBv5lEPDsz6xDVb7vHOTJpiMXIUUvJ4Z480A6EF0wIwTB0xVvElIR/Az6ys4FkO1A+jo6udevoLob1PO4VwwZjqFY+YTLtkGBbtvrrbfQNJTMagZTf4Z2NNmQ4sHI6b4ge5wE+CD+fCE1wSh9IU+HjWp6wkKaKQXSdvzxFFf5lf0N0UiZHzRyE99vK3tWw9a+jyNMZb067WYPV/aXGB1Doko3v9x0zklKFUx4nJG3iIQ09fQIXQQUMNV8f5FypJubzYu+uvx8/zXQk98Jx4vI9jPVJS6S7d
$ sudo systemctl -al | grep docker
  sys-devices-virtual-net-docker0.device   loaded    active   plugged   /sys/devices/virtual/net/docker0
  sys-subsystem-net-devices-docker0.device loaded    active   plugged   /sys/subsystem/net/devices/docker0
  var-lib-docker-btrfs.mount               loaded    active   mounted   /var/lib/docker/btrfs
  docker.service                           loaded    active   running   Docker Application Container Engine
  docker.socket                            loaded    active   running   Docker Socket for the API

上記で、idcfというユーザーが追加され、SSH公開鍵の設定が実施されている事と、Dockerサービスが自動起動するよう設定が変わっていることがわかります。 ここまでCoreOSテンプレートの使い方の基礎について解説いたしました。ただ、CoreOS自体が頻繁にバージョンアップしていることから、本記事の内容が正常に当てはまらなくなる場合がございます。その場合はCoreOSのコミュニティなどから最新情報を取得していただきますよう、お願いいたします。

次回、CoreOSのテンプレートの作成手順、カスタマイズ手順についてご紹介する予定です。お楽しみに。

参考リンク:CoreOS Documentation

IDCFクラウド関連サービス 新機能のご紹介

$
0
0

こんにちは。オンライン開発部の谷口です。

 

IDCフロンティアでは10月のIDCFクラウドリニューアルを皮切りに、関連サービスが日々アップデートされており、目が離せませんね。

さて、今回は11月以降にアップデート・リリースされた機能やサービスについてご紹介したいと思います。

コンテンツキャッシュ

多くのお客さまからご要望いただいていたコンテンツ配信に特化したサービスをリリースしました。

本サービス「コンテンツキャッシュ」は、月間平均624億PV*に上る、Yahoo! JAPANを支えるコンテンツ配信技術をベースにサービス化したものです。

9円/GB、使った分だけのお支払いで、簡単な設定でご利用いただけます。

アプリのメンテナンス明け、ECサイトのセール時などのアクセス急増のタイミングだけ、ちょっこっと使いたい時に使える配信サービスです!

CDNを使いたいけど、契約期間や初期費用などが高額でなかなか手が出せない、、、(涙)といった方に最適です。

 

*2014年7月~2014年9月の月平均。出所:2014年度第2四半期決算説明会資料

f:id:toshimi727:20160226102747p:plain

コンテンツキャッシュ利用方法

利用方法は簡単

1、(お客さま)お申し込み

お申込書をダウンロードいただき、必要事項をご記入のうえご返送ください。

(お申込書:http://www.idcf.jp/pdf/network/contentscache_order.docx

2、(弊社作業)キャッシュサーバー設定

3、(お客さま)DNS設定変更

4、キャッシュするコンテンツの設置

以上です。

利用していない時は、費用がかかりませんので安心してご利用いただけます。

 

コンテンツキャッシュ

http://www.idcf.jp/network/cache/
 

ネットワーク定額

IDCFクラウドでは、ネットワーク利用料がネットワーク転送量に応じて計算される従量料金となっています。

しかし、従量料金の場合予算が立てにくく、社内稟議を通すのが難しいという声を多くいただきます。

そこで、IDCフロンティアではご要望にお応えして、ネットワーク定額オプション(月額30,000円(税抜き))を開始しました。

ネットワーク費用

 

ネットワーク定額オプションのメリットは、ネットワーク費用が積みあがらず、月額30,000円固定のため、費用の計算がしやすく予算が立てやすいところです。例えば、社内向けのファイルサーバーやERPシステムなどトラフィックが安定しているシステムに向いています。

注意点としては、ネットワーク定額オプションのご契約では100Mbpsでネットワークの上限設定がされておりますので、トラフィックがバーストするようなサービスの場合は、従量タイプのご利用をおすすめします。

従量からネットワーク定額オプションにプラン変更する場合、お客さま固有の仮想ルーター(冗長)が再起動しますので、ネットワークの瞬断が発生します。

従量タイプの場合も毎月3TBまでの無償枠を設けておりますので、外部との通信が少ないサービスでしたら従量料金のほうがお得です。

 

IDCFクラウド インターネット接続

http://www.idcf.jp/cloud/spec/internet.html#SECTION01
 

オブジェクトストレージ10TBパック

システムのログ、サービスで利用している画像、コンテンツのアーカイブなど大量データを保存される方向けに「オブジェクトストレージ10TB」パックを提供開始しました。

オブジェクトストレージのご利用料金は毎月の利用量に応じて計算される従量課金となっています。

ストレージ利用料(月間平均)+ネットワーク転送量(Outトラフィックのみ)の合計で料金を計算します。

オブスト従量.004

今月のご自身の利用量は、オブジェクトストレージのコントロールパネルからご確認いただけます。

IDC Frontier ObjectStorage_2-2

従量課金の場合、7.8円/GB×ご利用量(月間平均)がかかりますので、もし10TBご利用いただくとストレージ利用量だけで月額78,000円(税抜き)かかりますが、10TBパックにお申し込みいただいた方は月額:32,000円(税抜き)でご利用いただけます!半額以下です!

社内にあるハードディスクの置き換えや、複数のクラウド・データセンターのデータバックアップ先など、予めデータ保存容量が4TB~16TB程度になることが見込まれているかたは10TBパックのご利用をお勧めします。

10TBパック

オブジェクトストレージ

http://www.idcf.jp/cloud/storage/

もっと詳しく聞きたい!という方はご遠慮なくお問い合わせください。

https://www.idcf.jp/inquiry/
 

<関連記事>

IDCFオブジェクトストレージサービス × ownCloud

MySQLのmysqldumpをオブジェクトストレージへ保存

30分でできる!オブジェクトストレージへのログ保存(s3cmd + logrotate編)

30分でできる!オブジェクトストレージへのログ保存(fluentd編)

 

 

 

IDCFクラウド 追加ネットワークを作成し、仮想マシンに接続してみる

$
0
0

はじめまして。UX開発部の梶本です。サービス開発のプロジェクトマネジメントやサービスマネジメントを主にやってます。先日、IDCFクラウドでネットワーク関連で2つの機能を追加しました!今回は追加ネットワークについて、操作方法を含めてご紹介します。プライベートコネクトは続編になります。

・追加ネットワーク

・プライベートコネクト

IDCFクラウドはアカウント作成時からプライベートネットワークを利用でき、開発中のサーバーをインターネットに晒すことなく開発できるのですが、このプライベートネットワークが追加できるようになりました!2つまで追加でき、合計3つまで利用できます。

今回の機能追加にともない、クラウドコンソールの画面に「ネットワーク」が追加されています。名前だけ見るとファイアウォールやロードバランサーなどのネットワーク系の機能の設定もできそうですが、これらの設定はIPアドレスごとに設定するため「IPアドレス」のメニューから設定できます。お間違えなく!

 

追加ネットワークの作成方法

 

それでは利用方法をご紹介します。まずは左側のメニューから「ネットワーク」をクリックします。

ネットワーク画面.1

 

続いて右上でやたらと目立っている「ネットワーク追加」ボタンをクリックします。

ネットワーク画面.2

出てきたウインドウに「ネットワーク名」や「ネットワークCIDR」を設定して「追加する」をクリックすれば完了です。簡単なので気軽にやってしまいそうですが、追加ネットワークは20円/時(税抜)の料金がかかります。無料だと思ってやってしまった!という方はすぐ削除すれば利用時間が短く、おそらく料金が1円未満になるため、お金はかかりません。

ネットワーク画面.3

※「ネットワークCIDR」は好きなプライベートIPアドレスを設定できます。CIDRは/23より大きいサイズを選んでください。一度作ったネットワークサイズは変更できないので、あまり小さいと仮想マシンで必要なIPアドレス数が足りなくなってしまうかもしれません。

※「DHCP割り当て範囲」は仮想マシン作成時に自動で割り当てるIPアドレス帯を決められます。このDHCP範囲ではないアドレス帯はVIPやセカンダリIPアドレスなどで利用できますが、「システム予約」とされているIPアドレスは使えませんのでご注意ください。

 

数秒で新しいネットワークが追加されました!追加したネットワークが表示されたら終了です。続いて仮想マシンとの接続方法をご紹介します。

ネットワーク画面.4

 

 

仮想マシンと追加ネットワークの接続方法

作成した追加ネットワークと仮想マシンの接続方法は2通りあります。

 

  1. 作成済み仮想マシンのNICを追加
  2. 仮想マシン作成時に接続するネットワークを指定

 

上記の方法で仮想マシンとネットワークを設定したら、OS上でネットワークを認識させる必要があります。CentOS7.0では自動で認識してくれるので、ここでは標準テンプレートのCentOS7.0を前提にすすめます。

 

まずは1の作成済み仮想マシンにNICを追加してみます。クラウドコンソールの「仮想マシン」をクリックし、接続したい仮想マシンの「仮想マシン名」をクリックします。

 

仮想マシンNIC追加.1

 

出てきたウインドウの「NIC」をクリックします。

仮想マシンNIC追加.2

 

追加したネットワークが表示されていますので、仮想マシンのIPアドレスをDHCPか手動で設定し、「+」をクリックして完了です。

仮想マシンNIC追加.3

 

ネットワークの接続が完了すると仮想マシンの一覧画面の「IPアドレス」の項目に複数のIPアドレスが表示されます。

仮想マシンNIC追加.4

 

続きまして2の仮想マシン作成時に作成したネットワークを接続してみます。まずは左側メニューの「仮想マシン」をクリックし、「仮想マシン作成」をクリックしてください。

仮想マシン作成.1

 

出てきたウインドウで、仮想マシンタイプ、イメージ、ボリューム、SSH Key、仮想マシン台数の設定を行っていくと、次にネットワークインターフェースの設定が出てきます。ここで仮想マシンと接続させたいすべてのネットワークをチェックし、詳細情報の設定で仮想マシン名、プライベートIPアドレスを指定して、仮想マシンを作成すれば完了です。

※ネットワークの選択で標準ネットワーク(network1)のチェックを外すと、インターネットへの経路が一切ない仮想マシンを作ることができます。

仮想マシン作成.2

 

仮想マシン一覧に作成した仮想マシンが表示され「IPアドレス」の項目に複数のIPアドレスが表示されていれば無事完了です。お疲れ様でした。

今回は標準CentOS7.0で試しましたが、OSによりますが、基本的にはOS上でネットワークインターフェースの追加が必要になります。例として標準テンプレートのCentOS6.5の設定例は次になります。

仮想マシン作成.3

 

[CentOS6.5の設定例]

  • 追加NICの設定方法
 # vi /etc/sysconfig/network-scripts/ifcfg-eth1
    DEVICE=eth1
    ONBOOT=yes
    BOOTPROTO=dhcp
  • 追加NICの有効化
 # ifdown eth1 ← eth1を停止
    # ifup eth1 ← eth1を起動

※クラウドコンソール上で仮想マシンのNICを追加し、削除して再度NICを追加するなどの操作をくり返すとeth1がeth2やeth3になったりしますのでご注意ください。

 


サクサクサイトの秘訣はこの二人が知っている!GYAO!も登壇、高負荷解消セミナー

$
0
0

12月24日(水)、東京(六本木)と大阪(梅田・東京会場の同時中継)で開催される「9円/GBからの高速配信!高負荷解消セミナー─日本最大級の動画ステーションGYAO!における配信のポイントとは?─」新規ウィンドウを開きます  本セミナーでご紹介するIDCフロンティアのコンテンツキャッシュサービスマネージャー 藤咲と技術担当 佐藤にインタビュー。当日はこの二人が講師を務めます!

 

■今回のセミナーの内容は?

藤咲:株式会社GYAO 開発本部の今野氏をお迎えして、アクセス集中に備えてどのような取り組みをしているのか事例を交えながらのご説明や、コンテンツキャッシュサービスの利用方法に関するデモを通してサーバーの負荷軽減やトラフィックの急増といったコンテンツ配信に伴うお悩み解決のヒントをお伝えできればと思っています。

佐藤:GYAO 今野さんにうかがった、動画においても重厚かつ壮大なCDNでなく、手軽にキャッシュが利用できるようになってきた技術トレンドは非常に興味深かったですね。当日は、日本最大級の動画ステーションが、どのような配信基盤でアクセスのピークを捌いているのか、採用している技術やトレンド、今後の方向性等、裏側をとことんお話いただく予定です。

 

R&D室 藤咲 コンテンツキャッシュ サービスマネージャー。サービス企画、仕様策定などにくわえ、プロジェクト管理・推進を行う。
R&D室 藤咲
コンテンツキャッシュ サービスマネージャー。サービス企画、仕様策定などにくわえ、プロジェクト管理・推進を行う。

■Yahoo! JAPANを支えるコンテンツ配信技術とネットワーク設備を基にIDCフロンティアでサービス化したのが「コンテンツキャッシュサービス」ですよね。ヤフーとの技術コラボは最初から決まっていたのですか?

藤咲:そうですね。ヤフーとのシナジーを活かした様々な取り組みの一環として、IDCフロンティアが、ヤフーの自社サービスのトラフィックを捌くために独自に開発・運用する優れた技術を活用して、お客様にご利用いただくことはできないかということでできたものです。

とはいえ、どんなプロジェクトでも同じだと思いますが、リリースまでには色々な課題がありました。ヤフーの関係者の方々のご協力によるところが大きかったですね。

(*「2014年度第2四半期決算説明会資料」によると2014年7月~ 2014年9月の月平均で624億PV)

 

R&D室  佐藤 コンテンツキャッシュ 技術メイン担当。サービス開発、保守運用。SEとして顧客への提案などを行う。
R&D室  佐藤
コンテンツキャッシュ 技術メイン担当。サービス開発、保守運用。SEとして顧客への提案などを行う。

■佐藤さんは今回ヤフーに常駐して開発を行っていましたが、いかがでしたか?開発段階の苦労などはありましたか?

佐藤:やはりヤフーは巨大な技術者集団ですので、プログラミングの環境とか情報共有のツールとか開発するにはいい環境ですよね。正直うらやましい部分もあります(笑)。 技術交流や人的交流ができてエンジニアとしてはとてもよい刺激になりました。

メインとなるキャッシュサーバーの技術はヤフーで開発、運用されているものを参考に設計、構築しましたが、そのキャッシュサーバーとIDCFネットワークとの接続方法、キャッシュサーバーとコントロールパネルの連携部分、特にコンパネの設計は全くのゼロからだったので苦労しました。

 

■アクセス集中時のサーバー負荷軽減やリッチコンテンツのレスポンス高速化に効果的なサービスだと思いますが、具体的におすすめの用途は?

藤咲:キャンペーンやゲーム・アプリのスタート時、メンテ明けのファイルダウンロードなど、アクセスがどのくらい集中するか予測が難しい際などに、簡単に準備できる高負荷対策としてご活用いただければと思います。完全従量制なので、もし思ったほどトラフィックが伸びなかった時は余計な費用もかからないですし。

また恒常的にトラフィックの多い、ECの商品画像やオンライン広告配信などにもお使いいただけます。増え続ける画像などの静的コンテンツはオブジェクトストレージに置いてコンテンツキャッシュから配信し、動的コンテンツはIDCFクラウドでスケールさせればさらに効率的です。

 

■そうなると、やはりIDCFクラウドのコンソールからコンテンツキャッシュも申し込みや設定ができるといいですね。

佐藤:まさに今やっているところです!IDCFクラウドとコンテンツキャッシュのコンパネの連携やAPI対応など、今期中にさらに機能強化したいと思っています。

 

■今回価格もかなり頑張りましたよね?(ヤフー系、アマゾンの半額以下でゲーム配信支援(日経電子版)新規ウィンドウを開きます

藤咲:はい(笑)。単価という意味でもそうですが、同様のサービスでは、リクエスト課金やオリジン転送料が別だったりして結局いくらなの?というのがわかり辛い。当社の場合は単純に外に出ていくトラフィックに対して1GBあたり9.0円という課金だけなので、非常にわかりやすいと思います。期間や従量の縛りもないので、本当に使いたい時に使った分だけ支払えるサービスです。

佐藤:性能面でもとにかく早く配信されるようなチューニング、ハードウエア構成を追求しています。

シンプルでパワフル最近のうちのサービスに共通するコンセプトですよね。


 

終了後は、ご希望に応じて、初期設定のレクチャーや、個別相談も対応いたします。この二人に色々聞いてみたいという方は是非ご参加ください!

「9円/GBからの高速配信!高負荷解消セミナー─日本最大級の動画ステーションGYAO!における配信のポイントとは?─」新規ウィンドウを開きます

IDCFクラウドについてのブログまとめ

$
0
0

こんにちは。オンライン開発部の谷口です。 12/25ブログまとめをupdateしました!

先日(2014/10/15)、リニューアルをしてリリースしたIDCFクラウドについて、多方面で反響をいただき社内でもうれしい悲鳴があがっています。

「500円で(ちゃんと)使えるクラウド」として、各方面で取り上げていただいており、早速多くの方にお試しいただき、ブログ等に掲載いただいておりますので、現時点で確認できたものをまとめて掲載させていただきます。

簡単に私の自己紹介。IDCF歴:もうすぐ二桁・・・結構長いです。

はじめは、当社ホスティングサービスのカスタマーサポートをやってました。その後営業職を経て、現在はオンライン開発部に所属し、主にクラウド、ビッグデータ分析サービスのマーコムを担当しています。以後、お見知りおきを。

それでは、ブログまとめ(2014/11/4時点2014/12/25時点をご紹介します!

▼IDCFクラウドの技術的特徴と基本性能をチェックする(2014年11月)(2014/11/20up)※12/25追記

www.atmarkit.co.jp

→アイティメディア株式会社の@ITに記事を書いていただきました!基本機能について詳細に書いていただいています。

▼IDCFクラウドのベンチマーク評価(2014年11月)(2014/11/28up)※12/25追記

www.atmarkit.co.jp

→アイティメディア株式会社の@ITに記事を書いていただきました!IDCFクラウドの仮想マシンをベンチマーク評価いただきました。それにしても、中の人インタビューがぶっちゃけすぎてて、変な汗出てきます。。。(笑

▼【移転予定】2015年1月5日(月)xebps.netは自宅サーバからIDCFクラウドへ(2014/12/3up)※12/25追記

xesoftware.blog.fc2.com

→移設の宣言をいただき、ありがとうございます!!移設のイメージ画像に白河データセンター画像を使っていただいて、「ププ(○´艸`)」っとしました。

▼新サービスIDCFクラウドのベンチマーク~IDCF従来のサービスやニフティクラウドType-eとの比較(2014/10/31up)※12/25追記

http://inaba-serverdesign.jp/blog/20141031/idcfcloud_benchmark_vs_nifty.html

http://inaba-serverdesign.jp/blog/20141031/idcfcloud_benchmark_vs_nifty.html

▼IDCFクラウドハードウェア専有「超高速マシン」のベンチマーク(2014/11/29up)※12/25追記

http://inaba-serverdesign.jp/blog/20141129/idcfcloud_iomemory_benchmark.htmlinaba-serverdesign.jp

▼WebサイトのサーバーをIDCFクラウドに移行(2014/11/20up) ※12/25追記

http://inaba-serverdesign.jp/blog/20141120/migrate_sakura_idcf.htmlinaba-serverdesign.jp

▼新サービスIDCFクラウド~従来の「IDCフロンティアセルフクラウド」との違い(2014/10/31up)※12/25追記

http://inaba-serverdesign.jp/blog/20141031/idcfcloud.html

→サービスリリース後、他社サービスとのベンチマーク比較など複数本のブログを書いていただいております。提供者としてはドキドキしますが、注目いただいておりとても光栄です!

▼Mackerelを使ってみる(2014/11/14up)※12/25追記

http://blog.hiroaki.home.group.jp/2014/11/mackerel.htmlblog.hiroaki.home.group.jp

→IDCFクラウドでご利用いただける注目機能“Mackerel”をお試しいただきました。MackerelもIDCFクラウドもまだまだ進化を続けますので、ご期待ください。

▼500円からのクラウド“IDCFクラウド”を利用した(2014/11/29up)※12/25追記

focusmark.jp

→弊社渾身のIDCFクラウドの管理画面を「スマート」と表現していただき嬉しいです!開発の担当者も涙目。。。

▼IDCFクラウド①アカウントを作った後にすること(2014/11/17up)※12/25追記

qiita.com

▼IDCFクラウド②Webサーバを立てて負荷分散を設定してアクセスしてみる(2014/11/17up)※12/25追記

qiita.com

▼IDCFクラウド③固定IPで外部インターネットにアクセスしてみる(2014/11/17up)※12/25追記

qiita.com

→アカウント作成後にやるべきことをまとめて書いていただいております!

とってもわかりやすいので、IDCFクラウド初心者の方はチェックチェック!!

▼IDCFクラウドでWINDOWS 10 TECHNICAL PREVIEW 動作検証 ~その1・インストール(2014/10/23up)※11/4追記

http://blog.oyasu.info/2014/10/23/3647/blog.oyasu.info

▼IDCFクラウドでWINDOWS 10 TECHNICAL PREVIEW 動作検証 ~その2・ベンチマーク(2014/10/26up)※11/4追記

→短期間の間に二つもブログ書いていただき、ありがとうございます!IDCFクラウドはWindowsもご利用いただけます~

http://blog.oyasu.info/2014/10/26/3687/blog.oyasu.info

▼IDCFクラウドを試してみる(2014/10/28up)※11/4追記

→仮想マシンの作成からMackerelの設定までお試しいただいております。 Mackerelって?!という方は是非ご一読ください~。ブログ記載ありがとうございます!

qiita.com

▼IDCFクラウド試用中(2014/10/29up)※11/4追記

→DigitalOceanなど他社クラウド利用経験から、IDCFクラウドのサービスやキャンペーン特長を簡潔にまとめてくださっています!ありがとうございます~

sho.tdiary.net

▼新しくなったIDCFクラウドの無停止でのオンラインスペックアップを試す(2014/10/29up)※11/4追記

→仮想マシンの作成から特長でもある「無停止スペックアップ」をお試しいただいております! IDCFクラウドはマシン作成の速度だけでなく、リサイズも爆速です!ありがとうございます~

heartbeats.jp

IDCフロンティアのクラウドでownCloud立ててみた(2014/10/30up)※11/4追記

→OwnCloudを使うと、自分独自のクラウドストレージを作れちゃいます。 皆さま便利なので、使ってみてください!当社ブログも見ていただいて、ありがとうございます!

blog.livedoor.jp

▼新しいIDCFクラウドを使ってみた(2014/10/15up)

→なんと、リリース当日にアップいただきました!すごい、速い!ありがとうございます!

tech.raksul.com

最速レビュー!安い、速い、「IDCFクラウド」(中の人)(2014/10/16up)

→IDCF中の人、入社2年目のエンジニアが書いています。惜しい、最速ではなかったけどIDCFクラウドの特長が良くまとまっています!

qiita.com

IDCフロンティアのクラウドを使ってみた(登録~仮想マシン作成~SSHログイン)(2014/10/16up)

→ヤフー中の人にも書いていただきました。ありがとうございます。

blog.noriaki.me

IDCFクラウドを体験する?(2014/10/18up)

→500円でご利用いただけるサーバーを使い倒していただいています。しかも、今なら無料ですしね!ありがとうございます!

dotnsf.blog.jp

話題の IDCF クラウドで Debian サーバーを一瞬で起動したい (2014/10/19up)

→ISOインポートや、My Templateの作成がわかりやすく説明されています。ありがとうございます。

http://engineering.otobank.co.jp/2014/10/19/debian-template-on-idcf-cloud/engineering.otobank.co.jp

【IT】月額500円のIDCFクラウドでBigBlueButton?(2014/10/20up)

→ubuntsuのインストール方法+BigBlueButtonのインストールが丁寧に解説されています!ありがとうございます。

http://kinoshitatadashi.com/?p=35kinoshitatadashi.com

▼IDCF クラウドを使ってみた(2014/10/21up)

→IDCFクラウド上でWordpressを立ち上げて、実際にブログを作られています。ありがとうございます。

学生でも使える500円クラウド!

http://blog.atgw.jp/archives/2916blog.atgw.jp

http://idcf.atgw.jp/2014/10/wordpress-on-idcfcloud/#more-16idcf.atgw.jp

今後も、blog書いていただけましたら、追記していきます。

主にtwitterから情報を拾っていきますが、「書いたよ!」という方は、twitterか、本エンジニアブログにコメントいただけると嬉しいです!

twitterアカウント:@idcfrontier

IDCFから冬休みの宿題です。(IDCFクラウド ロゴTシャツプレゼント!!)

$
0
0

宿題の提出は締め切りました。

たくさんのご応募いただき、ありがとうございました。プレゼント当選者の方には、メールで別途ご連絡をさせていただきます。

 

この年末年始に、IDCFクラウドを試してみようと思っている方へ、特別企画のご案内です!

IDCFクラウドでブログを立ち上げて、あなたのIDCFクラウド体験記を書いてみませんか。

ブログにIDCFクラウド体験記を書いてくださった方の中から抽選で3名様に、IDCFクラウドのロゴTシャツをプレゼントいたします!

冬休み、こたつでのんびり紅白観て、駅伝観て、特番観て、、、のお正月も良いですが、

自分のスキルアップのために使ってみませんか??

 

参考資料を以下にご案内いたします。 (公開期間:2015年1月12日(月・祝)まで)

こちらをを参考に、サーバー作成、Wordpressインストールまで挑戦してみましょう!

▼「サーバー初心者のためのWordPressサイト構築手順」

▼「付録:TeraTermを使ったSSH接続手順等」

 

IDCFクラウド ロゴTシャツ(表) IDCFクラウド ロゴTシャツ(表)[/caption]

IDCFクラウド ロゴTシャツ(裏) IDCFクラウド ロゴTシャツ(裏)[/caption]

▼宿題提出期間: 2014年12月27日(土)~2015年1月12日(月・祝)

#提出期間を過ぎてからの「宿題やったのに、家に忘れてきました。」は受け付けられません\(○`ε´○)

▼宿題提出方法:

メールでご連絡ください。

宛先:marketing@idcf.jpまで 件名:勇者求む!IDCFクラウド体験記!ロゴTシャツプレゼントお申し込み 内容:(1)お客さまのログインID (2)ブログのURL


(ブログURLは、必ずしもIDCFクラウドに構築したものでなくてもOKです!)

書いていただいたブログは、当社エンジニアブログでの紹介掲載もご相談させていただきます!

▼ご褒美発送 2015年1月30日(金)以降

※宿題提出いただいた全員の方に、結果のご案内をいたします。 ※ご褒美の発送は、アカウントにご登録いただいた住所宛となります。

IDCFクラウドは初めてという方から、ベテランの方まで、下記のポイントをご参考に、体験記をお待ちしております。

  • IDCFクラウドの機能や操作性で良かったこと、悪かったこと
  • 一言で表現するとしたら、IDCクラウドはどんなクラウド?
  • IDCFクラウドにこれから期待すること

スキルアップして来年を飛躍の年にしましょう~お待ちしております!!

CoreOS のVMware+CloudStack対応イメージ作成手順の紹介

$
0
0

f:id:toshimi727:20160225170400p:plain

前回の記事「IDCFクラウド対応CoreOSテンプレートをリリース」で、IDCFクラウド対応CoreOSテンプレートのリリースと基本的な使い方を紹介いたしました。

今回は、IDCFクラウド対応(VMwareとCloudStackに対応)CoreOSテンプレートの作成手順を紹介します。CoreOSテンプレートのカスタマイズ方法のヒントになればと思います。

以下、CoreOSの公式ドキュメントを参考に実際の手順を解説します。

1. VMDKの編集ができるLinux環境の準備

本手順の後半で仮想ハードディスクファイル(VMDKファイル)のマウントやサイズ変更などを行うので、事前にVMDKの編集ができるLinux環境を準備します。

1-1. VDDK for vSphere 5.5のインストール

VMDKを編集するためのツールとして、「** Virtual Disk Development Kit (VDDK)**」が公開されています。VDDKの利用条件として、64ビットOSが必要なので、64ビット版のLinuxサーバーを事前に用意します。VMware社のDeveloper Centerサイトから、VDDKの最新版(執筆時点での最新版は5.5.2)をLinuxサーバーにダウンロードします。なお、ダウンロードのためにはMy VMwareへの登録が必要となります。

次に、ダウンロードしたパッケージを展開、インストールしていきます。


# tar xvzf VMware-vix-disklib-*.tar.gz    (*はバージョン番号)
# cd vmware-vix-disklib-distrib
# ./vmware-install.pl
(VDDKインストールウィザードが開始される)

インストールが完了したら、のちに利用することになるコマンドへのパスが通っているか確認します。


# which vmware-mount
/usr/bin/vmware-mount
# which vmware-vdiskmanager
/usr/bin/vmware-vdiskmanager

1-2. OVF Toolのインストール

IDCFクラウドのテンプレートとして登録するためにはOVA形式でUploadする必要があります。VMDKからOVAファイルを作成するために、OVF Toolをインストールします。

まずOVF Tool配布サイトからLinux 64bit向けのインストールファイルをダウンロードします。ダウンロード後、以下のようにしてインストールを行います。ここではVersion 3.5.0を例にコマンド例を記載します。


# chmod 755 VMware-ovftool-3.5.0-1274719-lin.x86_64.bundle
# ./VMware-ovftool-3.5.0-1274719-lin.x86_64.bundle
(インストールが行われる)
# which ovftool
/usr/bin/ovftool

以上で環境準備が整いました。

2. CoreOS本家のビルド済み仮想マシンイメージの取得

CoreOS開発元では、各種IaaS向けのビルド済み仮想マシンイメージを配布しています。IDCFクラウドはHypervisorとしてVMware ESXiを利用しているので、以下のファイル名のファイルを下記の配布先からダウンロードします。

** ダウンロードするファイル **

  • coreos_production_vmware.vmx
  • coreos_production_vmware_image.vmdk.bz2

** 配布サイト **

配布サイトの最新情報はCoreOSドキュメントのページをご確認ください。

ダウンロードしたファイルはハッシュを念のため確認し、その後vmdkファイルを展開します。


# bunzip2 coreos_production_vmware_image.vmdk.bz2

3. CloudStack対応OEMスクリプトの追加

3-1. CloudStack対応OEMスクリプトのダウンロード

CloudStackのUser DataやSSH Key取得のためのスクリプトはGitHubのこちらの場所に公開されています。 これらのファイルすべてをLinuxサーバー上にダウンロードします。ファイルの役割は以下の通りです。

ファイル名役割
cloud-config.ymlCoreOS起動時にCloudStack対応スクリプトを実行するための設定ファイル
cloudstack-coreos-cloudinitCloudStackのUser Dataからcloud-config.ymlを取得して設定を実行するスクリプト
cloudstack-dhcpUser Dataなどの取得先IP(DHCPサーバーのIP)を取得するスクリプト
cloudstack-ssh-keyDHCPサーバーからCloudStackで設定されたSSHキーを取得し、coreユーザーのキーとして設定するスクリプト
coreos-setup-environmentCoreOSのEnvironment変数(/etc/environment)を設定するスクリプト

3-2. CoreOSのVMDKイメージへのOEMスクリプト追加

まず、CoreOSのイメージをLoopback Mountします。VMDKの保存先に合わせて/path/to/vmdk/は適切に変更してください。


#  vmware-mount /path/to/vmdk/coreos_production_vmware_image.vmdk 6 /mnt

重要なポイントは、OEMスクリプトを保存する場所はVMDKファイルの中の6番目のパーティション(CoreOS上では/usr/share/oem)であるという点です。

次に、マウントしたディレクトリの下にファイルを適切に配置します。CloudStack対応スクリプトの保存先に合わせて/path/to/script/は適切に変更してください。


# cp /path/to/script/cloudstack-* /mnt/bin/
# chmod 755 /mnt/bin/cloudstack-*
# cp /path/to/script/coreos-setup-environment /mnt/bin/
# chmod 755 /mnt/bin/coreos-setup-environment

設置したスクリプトをOS起動時に実行するよう、/mnt/cloud-config.ymlの内容にCloudStack用cloud-config.ymlの内容を追記します。追記結果については、次のNTP設定の結果と合わせて後程記載します。

3-3. IDCFクラウド用のNTP設定追加

IDCFクラウドではNTPサーバーも提供しているので、NTP参照先を変更します。そのために、write_files:セクションを/mnt/cloud-config.ymlに追記して/etc/ntp.confを作成するようにします。また、coreos>unitsセクションでNTPサービスを再起動するようにします。

また、TimeZoneをJSTに変更するためにcoreos>units配下にTimeZone設定コマンドを実行するよう記述します。

ここまでの手順をすべて行った結果、/mnt/cloud-config.ymlは以下の通りとなります。


#cloud-config

coreos:
  units:
    - name: settimezone.service
      command: start
      content: |
        [Unit]
        Description=Set the timezone

        [Service]
        ExecStart=/usr/bin/timedatectl set-timezone Asia/Tokyo
        RemainAfterExit=yes
        Type=oneshot
    - name: vmtoolsd.service
      command: start
      content: |
        [Unit]
        Description=VMware Tools Agent
        Documentation=http://open-vm-tools.sourceforge.net/
        ConditionVirtualization=vmware

        [Service]
        ExecStartPre=/usr/bin/ln -sfT /usr/share/oem/vmware-tools /etc/vmware-tools
        ExecStart=/usr/share/oem/bin/vmtoolsd
        TimeoutStopSec=5
    - name: cloudstack-ssh-key.service
      command: restart
      runtime: yes
      content: |
        [Unit]
        Description=Sets SSH key from metadata

        [Service]
        Type=oneshot
        StandardOutput=journal+console
        ExecStart=/usr/share/oem/bin/cloudstack-ssh-key
    - name: cloudstack-cloudinit.service
      command: restart
      runtime: yes
      content: |
        [Unit]
        Description=Cloudinit from CloudStack-style metadata
        Requires=coreos-setup-environment.service
        After=coreos-setup-environment.service

        [Service]
        Type=oneshot
        EnvironmentFile=/etc/environment
        ExecStart=/usr/share/oem/bin/cloudstack-coreos-cloudinit
    - name: ntpd.service
      command: restart

  oem:
    id: cloudstack
    name: CloudStack
    version-id: 0.1
    home-url: http://cloudstack.apache.org/
    bug-report-url: https://github.com/coreos/coreos-overlay

write_files:
  - path: /etc/ntp.conf
    content: |
      tinker panic 0
      # Common pool
      server -4 ntp1.noah.idc.jp burst iburst
      server -4 ntp2.noah.idc.jp burst iburst

      # - Allow only time queries, at a limited rate.
      # - Allow all local queries (IPv4, IPv6)
      restrict default ignore
      restrict -6 default ignore
      restrict 127.0.0.1
      restrict ::1
      restrict ntp1.noah.idc.jp nomodify notrap noquery
      restrict ntp2.noah.idc.jp nomodify notrap noquery

3-4. VMDKファイルの編集完了

VMDKの編集が完了したら、アンマウントとロック解除を行います。


# umount /mnt
# df
(/mntがマウントされていないことを確認)
#  vmware-mount /path/to/vmdk/coreos_production_vmware_image.vmdk -d
(VMDKへのロックを解除)

4. VMDKサイズ拡張とOVAテンプレート化

VMDKサイズはダウンロード当初は約8GB程度に設定されています。これをIDCFクラウド標準テンプレートのサイズである15GBに拡張します。


# vmware-vdiskmanager -x 15GB /path/to/vmdk/coreos_production_vmware_image.vmdk
  Grow: 100% done.
Disk expansion completed successfully.

WARNING: If the virtual disk is partitioned, you must use a third-party
         utility in the virtual machine to expand the size of the
         partitions. For more information, see:
         http://www.vmware.com/support/kb/enduser/std_adp.php?p_faqid=1647

次に、OVA形式に変換するため、ovftoolコマンドを実行します。/path/to/ova/はOVA保存先パスに適宜読み替えてください。


# ovftool coreos_production_vmware.vmx /path/to/ova/CoreOS_494.1.0_beta_64-bit.ova
Opening VMX source: coreos_production_vmware.vmx
Opening OVA target: /path/to/ova/CoreOS_494.1.0_beta_64-bit.ova
Writing OVA package: /path/to/ova/CoreOS_494.1.0_beta_64-bit.ova
Transfer Completed
Completed successfully

以上でOVAテンプレートファイルが完成しました。あとはIDCFクラウドのTemplateアップロード手順に従ってテンプレートの登録を行うことで、利用が可能になります。

今回、弊社提供CoreOSテンプレートの作成手順を解説しましたが、上記の手順を使えば、自分好みのカスタマイズも可能になります。ぜひお試しください。

IDCFクラウドのゾーン名はなぜ密度の単位「tesla」なのか?

$
0
0

IDCFクラウドのゾーン名「tesla」。ロケーション名が使われることなどが多いゾーン名に「tesla」というあまりなじみのない名前がついていることに疑問をもった方はいらっしゃるでしょうか?(全然気にならなかったor気づかなかったという方もいらっしゃると思いますが・・)

zone

実は、teslaは密度の単位なのですが、この命名にも開発者の熱い想いが込められているのです。IDCFクラウドの開発をリードした技術開発本部 UX開発部の寺門にその由来を聞いてみました。

テスラ(tesla)  国際単位系(SI)の磁束密度の単位。 1テスラは、磁束の方向に垂直な面1平方メートルあたり1ウェーバの磁束密度 (大辞泉より)

技術開発本部 UX開発部長 寺門
技術開発本部 UX開発部長 寺門

私たちは限られた範囲の中で凝縮された何かを日々作っています。IDCFクラウドのプロジェクトはまさにその代表格のようなもので、時間も人員もミニマムの体制でさまざまな密度を上げて対応してきました。

その結晶としてリリースするIDCFクラウドの最初のゾーン名には密度の単位「tesla」はぴったりだと思ったのです。

セルフクラウドでは、ゾーン名はjp-east-t1v、jp-east-t2vといったロケーションと数字の組み合わせでした。通常は1から始まりますよね。ユーザーも1と2があればほとんどの人は1を選びます。色や動物の案もありましたが、変に趣味嗜好が入るものにはしたくありませんでした。

・未来永劫存在するもの。 ・趣味思考が入らないもの。 ・順番がないもの。

という理由で単位をゾーン名に使うことに決めました。

いかがでしょうか?開発者のプロダクトに対する愛が垣間見えたような気がします^^

今後リリース予定の2ndゾーン以降にも単位名がつくそうです。

IDCフロンティアのコンテンツキャッシュサービスを使ってコンテンツを高速配信!

$
0
0

こんにちは。R&D室の佐藤博之です。

今回のエンジニアブログでは、IDCフロンティアのコンテンツキャッシュサービスを使ってコンテンツを配信する方法を紹介します。今回の構成では、オリジンサーバーにはIDCフロンティアのオブジェクトストレージサービスを使います。オブジェクトストレージサービスを使うことで、わざわざWebサーバーを構築することなく、簡単&安価に構成することが可能です。 このようにIDCFクラウドのロゴが表示されます。

IDCフロンティアのコンテンツキャッシュサービスについて

IDCフロンティアは2014年12月にコンテンツキャッシュサービスをリリースしました。世の中でいう、CDNサービスになります。コンテンツキャッシュサービスを利用することで、コンテンツを高速かつ安定的に配信できるほかに、オリジンサーバーの負荷軽減や突発的なアクセス増に対応できるようになります。

詳しいサービスの紹介についてはこちらをご参照ください。

構成

今回の構成は以下の通りです。オブジェクトストレージのバケット「idcfcache001」に保存したコンテンツ「idcfcloud.png」を、コンテンツキャッシュサービス内のキャッシュサーバーにキャッシュさせて配信します。エンドユーザーからアクセスするFQDNは「idcfcache001.cdn.jp.idcfcloud.com」とします。

実際にお客さまが利用する際は、バケット名、コンテンツ名、FQDNのすべてをお客さま側で決めていただきます。

demo_kousei

手順

以下の手順で、オブジェクトストレージをオリジンサーバーにし、キャッシュサーバーからコンテンツを配信します。

  1. IDCFクラウドでのアカウント作成

  2. IDCFクラウド コンソールからオブジェクトストレージ用APIキーの生成

  3. s3cmdのインストールおよびバケット作成

  4. オブジェクトストレージへのコンテンツアップロード(Cache-Controlヘッダー投入)

  5. コンテンツの公開設定

  6. DNSサーバーでCNAMEの設定

  7. 外部からのコンテンツアクセス

  8. Viaヘッダーの確認(キャッシュサーバーからレスポンスを返しているかの確認)

1. IDCFクラウドでのアカウント作成

今回の構成では、オリジンサーバーとしてIDCフロンティアのオブジェクトストレージサービスを利用します。オブジェクトストレージサービスはログやアーカイブ保管の他に、HTTP/HTTPSでのコンテンツ(画像、動画等)配信用途でも使うことができます。

IDCフロンティアのオブジェクトストレージサービスの紹介についてはこちらをご参照ください。

オブジェクトストレージを使うためには、IDCFクラウドのアカウントが必要になります。まずはIDCFクラウドにアカウントを作成します。

IDCFクラウドのアカウント作成方法は「めちゃ楽ガイド」をご参照ください。

2. IDCFクラウド コンソールからオブジェクトストレージ用APIキーの生成

作成したアカウントでIDCFクラウド コンソールにログインします。

画面上記の「東日本リージョン」から「オブジェクトストレージ」を選択します。

cloudportal-1

オブジェクトストレージのコンソールで「APIユーザー追加」を選択します。

cloudportal-2

リージョンで「EAST」を選択、APIユーザー名にメールアドレスを入力します。

cloudportal-3

APIキーが表示されます。

cloudportal-4

APIキーは後からでも確認可能です。APIユーザー名のリンクを選択すると、APIキーが表示されます。

cloudportal-6

cloudportal-7

3. s3cmdのインストールおよびバケット作成

続いてs3cmdのインストールとバケット作成です。s3cmdのインストール方法およびバケット作成方法は弊社でドキュメントを用意しております。こちらをご参照ください。

4. オブジェクトストレージへのコンテンツアップロード(Cache-Controlヘッダー投入)

s3cmdを使って、キャッシュサーバーにキャッシュさせたいコンテンツをオブジェクトストレージに保存します。その際、コンテンツにCache-Controlヘッダーを付与しておきます。Cache-Contorlヘッダーには、キャッシュサーバーに保存したい秒数を記述します。

以下の例では、idcfcloud.pngをキャッシュサーバーに600秒間キャッシュする形で、オブジェクトストレージへ保存しています。

ユーザーからコンテンツにアクセスされたタイミングで、キャッシュサーバー上のコンテンツがCache-Controlで設定されたキャッシュ時間を超過していた場合は、再度、オリジンサーバーへコンテンツを取得しにいきます。その際、コンテンツに変更があれば、キャッシュサーバー上のコンテンツを更新して配信します。コンテンツに変更がない場合は、キャッシュサーバー上のコンテンツをそのまま配信します。


# s3cmd --add-header=Cache-Control:public,max-age=600 put idcfcloud.png s3://idcfcache001/idcfcloud.png

5. コンテンツの公開設定

次にオブジェクトストレージに保存したコンテンツを外部公開します。オブジェクトストレージに保存したコンテンツはデフォルトではAPIキーをもったユーザーのみアクセス可能な状態になっています。

外部公開するために以下のコマンドを実行します。


# s3cmd setacl --acl-public s3://idcfcache001/idcfcloud.png

これで、バケット「idcfcache001」に保存したコンテンツ「idcfcloud.png」が外部公開されました。

Cache-Controlヘッダーが付与された状態で外部公開されているかを確認します。

オブジェクトストレージに保存したコンテンツは、

http://バケット名.ds.jp-east.idcfcloud.com/コンテンツ名

でアクセスすることができます。

curlコマンドを使いアクセスします。


# curl --head http://idcfcache001.ds.jp-east.idcfcloud.com/idcfcloud.png
HTTP/1.1 200 OK
Server: Riak CS
Last-Modified: Wed, 03 Dec 2014 12:23:06 GMT
ETag: "62dbc8827ca2018ca20c3278af861f71"
Date: Wed, 03 Dec 2014 12:25:33 GMT
Content-Type: image/jpeg
Content-Length: 17258
Content-Encoding: UTF-8
Cache-Control: public,max-age=600

上記の通り、Cache-Controlが付与された形のHTTPヘッダーが返ってくる状態であれば問題ありません。この状態はオブジェクトストレージが直接レスポンスを返しており、まだキャッシュサーバー側は使われていません。

6. DNSサーバーでCNAMEの設定

DNSのCNAMEを使って、キャッシュサーバー経由でレスポンスが返るようにします。DNSで以下のようにCNAMEを設定し、コンテンツキャッシュサービスにリクエストが送信されるようにします。

idcfcache001.cdn.jp.idcfcloud.com. CNAME cdn001.idcfcloud.com.

この設定後にidcfcache001.cdn.jp.idcfcloud.comにアクセスすると、キャッシュサーバー経由でレスポンスが返信されるようになります。

http://idcfcache001.cdn.jp.idcfcloud.com/

へのリクエストがオリジンサーバー(今回は、http://idcfcache001.ds.jp-east.idcfcloud.com/)

に送信される設定は、キャッシュサーバー側で行います。

※キャッシュサーバー側の作業は、IDCフロンティアのコンテンツキャッシュサービスに申し込みが完了次第、IDCF側で行います。IDCフロンティのコンテンツキャッシュサービスの申し込みはこちらから可能です。

7. 外部からのコンテンツアクセス

それではブラウザからアクセスしてみましょう。ブラウザはGoogle Chromeを使います。(HTTPヘッダーを確認できるブラウザであれば何でも構いません。)

HTTPヘッダーを確認するために、デベロッパーツールを利用します。デベロッパーツールはChromeの設定から「その他のツール」-「デベロッパーツール」で有効になります。

chrome

へアクセスしてみましょう。

http://idcfcache001.cdn.jp.idcfcloud.com/idcfcloud.png

このようにIDCFクラウドのロゴが表示されます。

idcfcloud-1

1回目のアクセスでは、キャッシュサーバーにidcfcloud.pngが存在しないため、キャッシュサーバーからオブジェクトストレージへidcfcloud.pngを取得しにいきます。その後、キャッシュサーバーは取得したコンテンツをユーザーへ返すと同時にキャッシュサーバー上のディスクにコンテンツをキャッシュします。

キャッシュの状態は取得したコンテンツのViaヘッダーに記載があります。有効にしたChromeのデベロッパーツールからヘッダー情報参照してみてください。

idcfcloud-2

HTTPヘッダーの最後の行にViaヘッダーが追加されています。[cMsSfW]がキャッシュの状態を表しています。今回は初回のアクセスのため、キャッシュサーバー側でキャッシュが存在しなかったことを表しています。

何度か更新してみましょう。以下のように、[cHs f ]の状態になると、キャッシュサーバーからキャッシュされたコンテンツが返されます。このときは、オリジンサーバーへのリクエストは発生しません。

idcfcloud-3

パフォーマンス比較

最後に、キャッシュサーバーから配信した場合とオリジンサーバーから配信した場合で性能を比較してみましょう。ベンチマークツールにはhttp_loadを使います。並列度を10にして、60秒間計測した結果が以下の通りです。

performance

オリジンサーバーからの配信に比べ、キャッシュサーバーからの配信が10倍以上早くなることが確認できます。IDCフロンティアのコンテンツキャッシュサービス内のキャッシュサーバーは、コンテンツ配信に特化したハードウェア構成、設定チューニングが行われており高速配信を実現しています。

最後に

今回はオリジンサーバーにオブジェクトストレージを利用しましたが、オリジンサーバーはIDCFクラウド上に構築した仮想マシンやデータセンター内の物理サーバーでも構いません。

コンテンツキャッシュサービス&オブジェクトストレージを使って配信している画像は、以下で公開しています。

http://idcfcache001.cdn.jp.idcfcloud.com/idcfcloud.png

是非、IDCフロンティアのコンテンツキャッシュサービスを活用して、コンテンツの高速配信を実現してください!

 

不正ログインを防ぐ2段階認証をいますぐ設定しよう(画面つき)

$
0
0

こんにちは。UX開発部沼野です。約3年ぶりのエンジニアブログです。 現在は、IDCFクラウドの開発に携わっています。UI設計、受け入れテスト等を行っており、最近では新規サービス開発も行っています。 個人的には、IoTを言い訳にArduino8pinoにセンサーやLED、LCDを取り付けて遊んでいますが、これらをどうやってネットに接続しようかと考えています。こちらは少しずつQiitaに投稿していきたいと思っています。

さて、今回はIDCFクラウドの2段階認証機能について、画面とともに紹介したいと思います。 想像してみてください。アカウントが不正利用されて、知らないうちに、月額179,000円のリッチな仮想マシンが20台起動していたら…? 「今すぐに2段階認証を使いたい!」という人は、[よくあるご質問]のこちらを参考に、設定してみてください。

それでは始めましょう。

2段階認証とは?

2段階認証は、従来のID/パスワード認証に加えて、認証コードを取得する2段階目の認証を行うことで、より安全にログインするための仕組みです。 2回目以降は従来の手順でログインできるので、ID/パスワードの盗難による第三者の不正利用の防止手段として、ご利用いただく事を推奨します。

IDCFクラウドでは、スマホアプリを使って、認証コードの取得を行います。 すでに、Google認証システム(Google Authenticator)アプリをご利用中の方は、同じアプリが使えます。

デフォルトでは「2段階認証:無効」となっていますので、2段階認証を利用する場合は、当該機能の有効化が必要です。 マルチユーザー機能を有するIDCFクラウドでは、マスターユーザーがアカウント内の他ユーザー全員に対して、認証ポリシーを設定する事が可能です。

IDCFクラウドで2段階認証を使おう

前提条件

以下の説明の前提条件として、IDCFクラウドにてアカウント登録とお支払い方法登録完了済である事とします。

まだ、IDCFクラウドにアカウントがない方は、めちゃ楽ガイドのSTEP1を参考にアカウント登録しましょう!

2段階認証の有効化

ユーザー毎に下記手順にて、2段階認証を有効化します。

1. 2段階認証を有効にしたいユーザーのログインIDでログインします。

login

2. クラウドコンソール画面右上のログインIDにカーソルを合わせ、「ユーザー情報」を選択します。

userinfo

3. 画面左側の「2段階認証」をクリックします。

2stepauth

4. 「アプリで認証する」をクリックします。

enable_2stepauth


5. 画面の手順を参考に、お手元のスマートフォンにアプリをインストールします。アプリを起動し、設定画面上のバーコードをスキャンします。

faq_sec_002_004

6. アプリで生成される6ケタの確認コードを入力し、「確認」ボタンをクリックします。

faq_sec_002_005

7. アプリでの2段階認証の有効化完了となります。

faq_sec_002_006

8. [ ユーザー情報]に登録済のメールアドレスに、2段階認証有効化完了メールが届きます。

2step-regist-mail

バックアップコード

スマートフォン紛失等で認証コードを確認できない場合に備えて、事前にバックアップコードを確認しておきましょう。

1. クラウドコンソール画面右上のログインIDにカーソルを合わせ、「ユーザー情報」を選択します。

userinfo

2. 画面左側の「2段階認証」をクリックします。

2stepauth

3. 「バックアップコードを表示する」をクリックします。

backupcode


4. 10個のバックアップコードが表示されます。印刷かファイル保存して、いざと言う時に参照できるように大事に保管してください。それぞれのコードは1回しか使用できません。10個のコードを使い切った場合もしくは、再度バックアップコードを再作成したい場合には、画面下部の「新しいコードを生成」をクリックしてください。

2step-backupcode

認証ポリシーの設定

マルチユーザー機能を有するIDCFクラウドでは、マスターユーザーがアカウント内の他ユーザー全員に対して、認証ポリシーを設定する事が可能です。2段階認証の「必須/任意」等を設定を行います。認証ポリシーは全ユーザーに対する一括設定と、ユーザー毎設定どちらも可能です。

以下、認証ポリシーとして、2段階認証:必須の設定方法を説明します。

1. マスターユーザーとしてログイン。認証ポリシーを設定できるのは、マスターユーザーのみです。

login


2. クラウドコンソール画面右上のログインIDにカーソルを合わせ、「ユーザー情報」を選択します。

userinfo


3. 画面左側の「2段階認証」をクリックします。

2stepauth

4. 認証ポリシー「2段階認証を必須にする」を選択する。

(2段階認証必須後、2段階認証未登録のユーザーは、画面上部に2段階認証登録を促すメッセージが表示され、2段階認証登録が完了しないと他の画面の操作ができなくなりますので、ご注意ください。)

hissu_2stepauth_2


5. 確認画面が表示されるので、内容を確認し、「はい」をクリック。

confirm_2stepauth

6. 2段階認証未登録のユーザーは(マスターユーザーも含めて)、画面上部に2段階認証登録を促すメッセージが表示されますので、上述の手順に従って、2段階認証登録を行ってください。

notice_2stepauth_2


7. また、マスターユーザーおよびマスターユーザー以外のユーザーには下記のような認証ポリシーが変更された旨のメールが届きます。 このメールを受信したユーザーは、速やかに2段階認証登録を実施しましょう。

mail_hissu_2stepauth


特定ユーザーのみ認証ポリシーを変更

何らかの理由にて、特定のユーザーのみ認証ポリシーを変更したい場合は、マスターユーザーにて設定可能です。

1. マスターユーザーでログイン後、[ユーザー情報]-[マルチユーザー]をクリックします。

multiuser

2. 認証ポリシーを変更したいユーザーをクリックします。

click_user

3. ?ユーザー編集画面にて「認証ポリシー」を変更します。

change_policy_user

4. 変更内容を確認し、「はい」をクリックします。

confirm_change_policy_user

全ユーザーの認証方法確認方法

マスターユーザーにて確認可能です。

  1. マスターユーザーでログイン後、 [ユーザー情報]-[マルチユーザー]をクリックします。

multiuser

  1. ?ユーザー一覧の「2段階認証」列にて、各ユーザーの2段階認証登録状況が確認できます。

下記例だと、一番下のユーザーのみ、2段階認証が有効になっていることが分かります。

multiuser2

2段階認証でログイン

最後に2段階認証有効化済のユーザーでログインしてみましょう。

1. ログイン画面にて。ログインID/パスワードを入力。

login

2. 次に2段階認証画面になるので、アプリを起動し、表示された6桁のコードを入力します。認証完了すれば、クラウドコンソール画面が表示されます。

input_2stepauth

3. もし、上記ステップで、スマートフォンを紛失した等の理由でコードを入力できない場合は、画面右下の「バックアップコードを使う」をクリックします。

input_2stepauth2

4. 予め保管しておいたバックアップコードを入力します。バックアップコード入力後、クラウドコンソール画面が表示されます。

input_backupcode

5. バックアップコード使用時には、ユーザーに対してバックアップコード利用した旨のメールが送信されますので、残りのバックアップコード数を確認してください。 ログイン後、[ユーザー情報]-[2段階認証]内の「バックアップコードを表示する」では残りのバックアップコードを確認する事ができます。

mail_backupcode

backupcode2

まとめ

  • 今回は、IDCFクラウドの2段階認証の設定方法・ログイン方法を紹介しました。
  • この機会に、ぜひ2段階認証を利用いただき、お客様のセキュリティレベルを1段高めていただければと思います。

オープンデータ活用の課題に挑むチーム「AERIAL」

$
0
0

「エンジニアもすなるエンジニアブログというものを、非エンジニアもしてみむとてするなり」。こんにちは。サービスディベロップメントグループの渡邉です。非エンジニアです。読みにくい部分もあるかと思いますが、ご容赦ください。

さて、世の中、オープンデータ、オープンデータと騒がれて久しいですが、いざ何かしようとすると、「どこに何のデータが公開されているのかわからない」、「公開されいている形式がバラバラ」、「データが加工しにくい(罫線つきのExcelとか、PDFとか(!))」、など様々な壁が立ちはだかります。

先日、4/11(土),12(日)の2日間、北野武のCMでもおなじみ(!?)DMM.make AKIBAで、「International Space Apps Challenge(以下「ISAC」) Tokyo 2015」が行われました。このハッカソンは、NASAやJAXAが公開しているデータを活用しようというもの。早くも今年で4年目になるそうです。

今回のエンジニアブログでは、ISACでIDCFクラウドを活用し、JAXAのオープンデータを一般のウェブ開発者でも使えるように、JSON形式に変換したものをAPI経由で提供したり、ドキュメントの整備を行っている、チーム「AERIAL」の活動をご紹介します。

◆サイト概要

まずは難しいことを抜きに、サイトをご覧ください。こちらがトップ画面です。

hi-rezclimate_1

URL:http://hi-rezclimate.github.io/

さすが宇宙をテーマにしたサイト、なんとも美しいですね!AERIALは、JAXAがG-portalというサイトで公開している、人工衛星の「しずく」のデータを、一般のウェブ技術者向けにJSON形式で配布します。JAXAから海面温度や降水量のデータが公開されているって、ご存知でしたか?漁業、農業、小売業、物流、観光…いろんな分野で活用できそうですね。

◆課題

しかし、オープンデータ活用にあたっては、冒頭でお伝えした通り、一般のウェブ開発者にとっての壁が存在ます。

JAXAがG-portalで公開している衛星のデータをダウンロードしようとすると、拡張子「.h5」がついています。非エンジニアの私には、一体.h5が何のアプリケーションで開くのか想像もつきません…!

ダウンロード

「.h5」は、HDF5というデータ形式の拡張子。HDF5はHierarchical Data Format 5の略で、科学技術計算などの分野で、時系列に変化する大量のデータを逐一記録するときなどによく用いられ、衛星データでは一般的に用いられているそうです。

このデータ形式は、「Hierarchical」の名の通り、一つのファイルの中に、データの他に、階層構造を持っています。ちょっと特殊ですね。HDF5を扱うためのマニュアルを覗いてみると…日本語なのに、頭に入ってこない…もう、即座にページを閉じるしか私には選択肢がありませんので、AERIALのリーダー大友さんに概要を解説いただきました。

衛星に搭載されたAMSR-Eというセンサーが取得するデータにはLevel0~Level3まで存在します。0を未処理のロウデータ、3が最も高次に洗ったもので、そのLevel3のデータフォーマットに関する定義書類が記載されています。そして、シーンごとの回転速とその際のデータの取得可能領域に関する説明等があり、海上風速、海表面温度のバックグラウンドで必要なアルゴリズムなどが記載されています。

これらを把握して、初めてAPIが返す値を正確に理解できるわけです。もう!XMLやJSONみたいに、データをそのまま吐き出してくれればいいのに…!

◆まずは使ってみよう

そのHDF5を、テキストベースのJSON形式に変換して配布するのが、AERIALです。試しに、今年2015年元旦の東京を中心とした積雪量のデータを取り出してみます。 緯度、経度、日にちなどを入力して、「Send」をクリックすると…

AERIAL_1

見慣れたJSON形式で出力されました!

AERIAL_2

同時にデータの内容が可視化されるので、確認もできます。

AERIAL_3

このさくっと変換できる手軽さ、そして、使いやすく美しいUIが、開発者の心をとらえてやみません!また、データの取得を行えるAPIが提供されているので、自作のプログラムで手軽に利用できます。衛星のデータが手軽に活用できるなんて、可能性が広がる気がしませんか?

◆アーキテクチャ

AERIALは、フロントとバックエンド、2台のサーバーで運用されています。 システム構成

  1. バックエンドの集計・解析用サーバーでは、定常的にHDF5形式のJAXAのデータをsftpで読み込んでいます。このデータを「h5dump」で標準出力ストリームにダンプし、JSON形式に変換。積雪量、降水量など情報の種類に応じエンドポイントを分け保存しています。
  2. フロントサーバーは、AERIALのUIの部分。ユーザーがUIで選んだ情報の種類に応じたアドレスで、サンプルコードを生成して表示させると同時に、JSON形式のデータを取りに行き可視化します。

◆ISAC 2015の2日間の成果物

AERIALは、第一回のISAC Tokyoから継続しているプロジェクト。今年のISACでは大きく2つの成果物がありました。

1.飲み水のデータを道案内

aerial-isac2015

URL:http://hi-rezclimate.github.io

自分がいる場所をGPSで特定し、最寄りの飲用水がある場所までの道順を、GoogleMapで案内するアプリケーションです。OpenStreatMapプロジェクトで世界中から寄せられた、40万レコードにも及ぶ井戸・水道のデータを、データベースで処理して表示させます。

2.システムトラブルに対応

AERIALが活動する前から、もともとJAXAでも公式に、HDF5のデータをJSONで配布するプロジェクトがありました。しかし、本ハッカソンの直前に、システムトラブルで配布が休止する事態に。チームAERIALが急遽、JSONでの配布がストップしたデータを、AERIALのサイトから配布できる体制を整えました。配布開始は1日目の27時(2日目の3時)といいますから、夜を徹しての作業です。

◆制作したのはプロフェッショナルな面々

IMG_5971

リーダーの大友さん(写真中央右)は、ISAC第1回からの参加者。第1回で40時間寝ずにハックしていたところ、JAXAにスカウトされ、中の人になってしまったという異色の経歴の持ち主です。

そこに第3回からジョインしたのが和智さんと白浜さん(写真左から)。グリーに勤務するお二人は、普段の業務でも毎日ハッカソンのような生活を送っているそう。ハッカソンとなると2日間の勝負なので、どうしてもUIの細部まで手が回らないことも多いのですが、高いクオリティで仕上げる「神」的な存在。ドキュメントをきれいに成形するのにも、本来、ノウハウ・テクニックが要るのですが、いとも簡単に実現します。

こちらの写真にはいらっしゃいませんが、第2回からジョインした中尾さんもコアメンバーの一人。HDF5からJSON形式に変換するエンジンを開発されています。

※写真右は、チーム「AERIAL」ではありませんが、第3回のISACに参加した当社のR&D室長の大屋です。写真の4人の対談の様子は、IDCフロンティアのコーポーレトブログ「チーム「AERIAL」から見たハッカソンレポート-International Space Apps Challenge 2015-」もご覧ください。

◆今後

AERIALには、将来、オープンデータのハブになる、という大きな構想があります。JAXAが公開しているデータだけでなく、省庁・団体を越えて様々なデータを提供することを目指しています。同時に、これらのデータを活用し、ハザードマップや危機予測にも対応できればとのこと。 また、ユーザインタフェース部分もより使いやすくなるよう、JavaScript SDKを開発し、オープンデータを活用する開発者の裾野を広げる考えです。

AERIALは、このプログラムの大部分をオープンソースで公開しています。以下のURLは、昨年と今年の開発分があるGithubのレポジトリです。

URL:https://github.com/hi-rezclimate

興味をもたれた方は、このプロジェクトにジョインしてみませんか?

IDCフロンティアのネットワークサービス(LB/WAF)を使った事例紹介

$
0
0

こんにちは、ネットワークイノベーション部 三浦です。 今回はIDCフロンティアのネットワークサービス(以下「IDCFネットワークサービス」)を使用した事例紹介をさせていただきます。

IDCFネットワークサービスとは?

IDCFネットワークサービスについて簡単に説明しますと、ファイアウォール(以下「FW」)/ロードバランサー(以下「LB」)/ウェブアプリケーションファイアウォール(以下「WAF」)の機能を選択して使用できるサービスです。その他にDDoS対策、IPS/IDSの機能も選択可能ですが、今回はFW/LB/WAFを中心にご紹介します。

特長としては、さまざまなネットワーク構成でご利用いただけることです。IDCFクラウドのゾーンやデータセンターを跨いだ構成や、IDCFクラウドの仮想マシンとお客さまマシンの負荷分散もできます。クライアント⇔サーバー間だけでなく、DB接続などのサーバー間の通信にも適用できます。 さまざまなネットワーク構成でご利用いただけます

どうやって実現している?

IDCFネットワークサービスではF5社のアプライアンス製品であるBIG-IPを使用しています。RouteDomainという機能で、下図のようにマルチテナントを実現し、RouteDomain毎に必要なサービスを適用しております。

BIGIP

RouteDomainをCLIで設定するとこのような感じです。BIG-IPはGUIで操作するのが一般的かもしれませんが、CLIもJunosチックで取っ付きやすいです。

id 101
   vlans {
       VLAN101-External
       VLAN1001-Internal
   }
id 102
   vlans {
       VLAN102-External
       VLAN1002-Internal
       VLAN103-External
       VLAN1003-Internal
   }
id 104
 vlans {
  VLAN104-External
  VLAN1004-Internal
       VLAN1005-Internal
   }

BIG-IPを使っているため、「現在オンプレ環境でBIG-IPアプライアンスを使用していて、クラウド環境に移行したい方」という方は既存の設定をそのまま(安価に)移設できます。事例で後ほどご紹介していきますね。また、SSLアクセラレーションや個別ヘルスモニター等の機能も標準サービスとして使えます。では事例の説明に入ります。

事例紹介

■WAFで速やかに脆弱性に対応した事例

PCIDSSでも推奨から必須となったWAFの活用事例をご紹介します。BIG-IPでいうとASMというモジュールの機能になります。

そもそも攻撃なんてあるの?

弊社のとあるサイトも毎日様々な国から様々な攻撃を受けています。脆弱性を放置することは大きなリスクです!

攻撃

内部ではこんな感じで攻撃の詳細が見れるのですが、残念ながらお客さまにお見せすることはできません。

sql

事例

あるサイトで、脆弱性検査の結果、クロスサイトスクリプティングとSQLインジェクションの攻撃に対して、脆弱であることがわかりました。

プログラムの改修には時間がかかるため、至急、サーバーの上位にIDCFのネットワークサービスを導入し、攻撃をきっちり防御しました。高価なWAFは攻撃を受けてから導入を検討されるケースが多いのですが、比較的安価なIDCFネットワークサービスのLBをご契約いただいた状態であれば、いつでもすぐにWAF機能を利用開始できます。

ご契約いただいているお客さまには毎日の簡易レポートと、ご要望に応じて詳細レポートをご提供しております。その一部を、ちょっとだけ貼りますね。

レポート

ちなみにシグネチャは毎日4:00に更新しています。

■iRuleの活用事例

IDCFネットワークサービスではF5社のアプライアンス製品であるBIG-IPを使用しているため、iRuleが利用できます。日頃運用していて「多いな」と感じるお客さまのご要望に対し、iRuleを使用して実現した事例をご紹介します。

ご要望1:暗号化が必要なサイトにリダイレクトしたい

下記のように、「クライアントからのHTTPアクセスをHTTPSにリダイレクトさせたい」というご要望に対応したケースです。セキュアな情報の入力等が必要なサイトで、ご要望が寄せられることがあります。

手順

iRuleの中身はこんな感じです。

when HTTP_REQUEST {
               HTTP::redirect https://[HTTP::host][HTTP::uri]
                   }

ご要望2:Sorryサーバーに自動で切り替えたい

運用中のサイトがダウンした際に、自動でSorryサーバーへ切り替える方法として、IDCFネットクワークサービスでは以下の3つパターンを用意しました。

  1. [パターン1] お客さまにてSorryサーバーをご用意いただき、お客さまのSorryサーバーに分散させる
  2. [パターン2] 外部サイトにリダイレクトする
  3. [パターン3] IDCフロンティアにてLB上にファイルをアップし、そのページにアクセスさせる(単一ファイルのみ)

SorryServer

iRuleの中身をご説明します。

パターン1については実はiRuleではなくPoolのPriority Group(+Priority Group Activation )で実現しています。

パターン2のiRuleはこんな感じです。先ほどご紹介したリダイレクトの設定と同じです。

when HTTP_REQUEST {
       if { [active_members &lt;strong&gt;Poolの名前&lt;/strong&gt;] &lt; 1 }
         {HTTP::redirect https://[HTTP::host][HTTP::uri] }
         }

パターン3のiRuleはこんな感じです。iFile Listに単一ファイルをuploadして、それを指定しています。

when HTTP_REQUEST {
       if { [ active_members &lt;strong&gt;Poolの名前&lt;/strong&gt;] &lt; 1 }
         {HTTP::respond 200 content [ifile get /Common/&lt;strong&gt;fileName&lt;/strong&gt;] &quot;Content-Type&quot; &quot;text/html&quot;
}
         }

ご要望3:特定の国からのアクセスを防ぎたい

特定の国からの攻撃は、WAFサービスでも防げるのですが、これをご利用でないお客さまでも、iRuleで実現することができます。「特定の国」を管理するデータベースは、更新頻度が高くないので、現場では月に1回、手動で更新しております(自動でできるようにならないかな。。。)。

iRuleはこんな感じです。下記では、日本からのアクセスを拒否しています。JPのところを別の国コードで記載すればその国からのアクセスは拒否されます。

when CLIENT_ACCEPTED {
  switch [whereis [IP::client_addr] country]
             {&lt;strong&gt;JP&lt;/strong&gt; { reject }}
            }

 ご要望4:iRuleをそのまま移設

他にもiRuleを利用した事例は多くありますが、一番多いのが既存の(オンプレの)iRuleをそのままIDCFネットワークサービスに移設というケースです。Version9以降のiRuleであればほとんどの場合そのまま移設可能です(とはいえ稼動前にしっかり試験することは大事です)。

 

■こんなご利用事例も

その他に、お客さまがIDCFネットワークサービスをこのように使用しています、という例をご紹介します。

事例1:クライアントのIPアドレスを変換せずにWEBサーバーに渡す

マーケティングや運用上の目的で、WEBサーバーでクライアントのIPアドレスを集計している場合は、クライアントのIPアドレスをそのままWebサーバーに渡す必要があります。多く寄せられるご要望のため、この機能はデフォルトで有効となっております。

 

事例2:プライベートファイアウォールとしてのご利用

お客さまのオンプレミス環境とIDCFクラウドを連携させたケースです。オンプレからクラウドへの移行や、「通信量が多い時だけクラウドのサーバーを使いたい」といったときにこのような構成をとられることが多いです。

このケースでは内部間の通信にファイアウォールが必須であったため、プライベートコネクトをIDCFネットワークサービスのFWで終端させ、通信を制御しました。

ハイブリッド

 

この場合、インターネットへの出口は、お客さまのオンプレミス環境でも、IDCFクラウドでも、どちらもご利用いただくことがきます。

事例3:想定外のトラフィック量に対応

IDCFクラウドが標準で提供する仮想ルーターでは処理しきれない大量の通信が発生した お客さまにて、高性能なIDCFネットワークサービスをご利用いただくことで問題なく通信を処理できるようにしました。

traffic-2

少し前であればアプライアンス製品の導入の際には、調査、選定、検証、構築、設置等(だいぶ省略しましたが)が必要でした。IDCFネットワークサービスは、ケーブル配線すら必要なく、手軽に機能も性能も向上させることができた、いい事例かと思っています。

 

事例はこんなところで。

 

IDCFネットワークサービスの今後

最後にIDCFネットワークサービスについての今後についてお伝えします。一部の設定、例えばお客さまサーバーメンテナンスなどで分散対象から外したい場合などについて、UIをご提供しております。現在のところ下のような画面です。このUIについては改善要望も多く、随時更新しています。

LBportal

今UIでできることは

◯LB

  • ノード(分散対象となるサーバ)の追加
  • ノードの削除
  • ノードの有効化
  • ノードの無効化

もうすぐUIでできるのが

◯FW

  • ルールの追加
  • ルールの編集
  • ルールの削除

といったところです。さらにUIをよくしていきたいので、すでにご利用中のお客さまはご意見いただけますと助かります。

このようにIDCFネットワークサービス(FW/LB/WAF)では十分に実績のある機能を組み合わせることで新しいサービス、新しい価値をご提供しております。拙い説明で、わかりづらい点もあったかと思いますが、ここまで読んでいただきありがとうございました。気になる点ございましたらお問い合わせくださいませ。

 

でわでわ

サーバーを起動したままスペックアップする

$
0
0

こんにちは、ソリューションアーキテクトの藤城(@tafujish)です。
私がお客さま先でIDCFクラウドのデモをやるとき、好評いただく機能の一つにダイナミックスケールがあります。聞き慣れないワードだと思いますがダイナミックスケールとは、サーバーが起動している状態で(すなわち無停止で)、VMのCPU/メモリをスペックアップできる機能です。
このダイナミックスケール、好評いただく一方で知らなかったという声もしばしばいただくので、 ここではダイナミックスケールを紹介します。

ダイナミックスケールは、新しい仮想化ハイパーバイザーと新しいOSを利用することにより安定して利用できるようになりました。また簡単に利用でき即時反映されますので、スケールアウトよりも素早くシステム性能を上げることができます。一時しのぎに使うのも便利ですね。

ダイナミックスケールを試してみよう

では実際に試してみましょう。
1) CentOS 6.6のVMをStandard.S4で作成します Standard.S4なので、1コアの4GBメモリとなります。  以下のコマンドで現在のCPUとメモリのサイズを確認します。

●メモリサイズ確認
    # <strong>free -m</strong>
                 total       used       free     shared    buffers     cached
    Mem:          3825        137       3687          0          7         42
    -/+ buffers/cache:         87       3737
    Swap:            0          0          0

    ●CPUコア数確認
    # <strong>lscpu</strong>
    Architecture:          x86_64
    CPU op-mode(s):        32-bit, 64-bit
    Byte Order:            Little Endian
    CPU(s):                1
    On-line CPU(s) list:   0
    ~以下略~

リサイズ前の値が、Memのtotalが4GB、CPU(s)が1コアなのがわかります。 2) ポータル上で対象のVMをリサイズします参考)【FAQ】仮想マシンのリサイズ手順 ここでは、一つ上のStandard.M8を選択します。 グレーアウトされているVMタイプはスペックダウンが伴うので選択できません。 数秒で完了の表示が出ます。どうです、速いでしょう!

3) スペックアップされたか確認します

 先と同じくアップ後のCPUとメモリのサイズを確認します。

●メモリサイズ確認
    # <strong>free -m</strong>
                 total       used       free     shared    buffers     cached
    Mem:          7921        210       7710          0          7         42
    -/+ buffers/cache:        160       7760
    Swap:            0          0          0

    ●CPUコア数確認
    # <strong>lscpu</strong>
    Architecture:          x86_64
    CPU op-mode(s):        32-bit, 64-bit
    Byte Order:            Little Endian
    CPU(s):                2
    On-line CPU(s) list:   0,1
    ~以下略~

以上、簡単にスペックアップできることがわかりました。 topコマンドで見ても反映されてるのがわかると思います

実際本番環境で使えるの?負荷試験してみる

先述のダイナミックスケールの際に、HTTPで負荷をかけながら実施して、サービス影響がどこまででるか、本当に性能がスケールするか確認してみましょう。お客さまと話ていても、ここが一番気になるようです。

1) Standard.S4でWEBサーバーを作成
2) WEBサーバーにApacheとPHPをインストール
3) コンテンツとしてphpinfoを返すだけのページを用意
4) このWEBサーバーに対して別のサーバーからHTTPリクエスト
5) WEBサーバーのCPUがボトルネックになるので、負荷かけながらStandard.M8へリサイズ

ダイナミックスケール負荷試験

上図は毎秒の秒間リクエスト数とレスポンスタイムのグラフです。リサイズ実施後に、処理数が向上しているのが確認できました。また、リサイズ実施のタイミングで処理数が低下していますが、レスポンスタイムに遅延は発生してないので、ユーザーからするとほぼ影響がないと思われます。リクエストタイムアウトやバッドリクエストも発生しませんでした(ずっと0だったのでグラフ描きませんでした)。確かに性能向上し、HTTPサービスへの影響もないことが確認できました。

ダイナミックスケールMackerel

上図はMackerelで見たCPUリソース状況です。リサイズ前にCPU100%で輻輳している様子と、リサイズ後はCPUリソースに若干の余裕ができました。Mackerelもダイナミックスケールに対応して、正常にグラフが更新されることが確認できました。

以上のとおり、リソースも実際の性能もスケールすることが確認できましたが、ミドルウェアやアプリケーションとそれらの設定によっては追加したCPU/メモリを活用できないかもしれません。例えば、メモリを増やしたらMySQLのinnodb_buffer_pool_sizeを増やす必要があります。ダイナミックスケールの後の設定チューニングでよりリソースを活用してもらえればと思います。

リサイズしたのにCPU・メモリが増えていない件

先述の例では、CentOS6.6で実施したため、リサイズしただけでOS上でCPUもメモリも増えていることが確認できたと思います。他のOSでは自動で有効化(オンライン化)されないケースもあります。
具体的には、CentOS7.1だとメモリが自動でオンライン化されません。Ubuntu14.04だとCPUもメモリもオンライン化されません。
では、Ubuntu14.04を例にオンライン化してみましょう。

Ubuntu14.04のVMをStandard.S4で作成し、その後Standard.L16へリサイズする例です。

●メモリをオンラインに
    # <strong>free -m</strong>
                 total       used       free     shared    buffers     cached
    Mem:          3946        553       3392          0         11        255
    -/+ buffers/cache:        286       3659
    Swap:            0          0          0
    # <strong>grep offline /sys/devices/system/memory/*/state</strong>
    ~以上略~
    /sys/devices/system/memory/memory131/state:offline
    /sys/devices/system/memory/memory132/state:offline
    /sys/devices/system/memory/memory133/state:offline
    /sys/devices/system/memory/memory134/state:offline
    /sys/devices/system/memory/memory135/state:offline
    /sys/devices/system/memory/memory40/state:offline
    /sys/devices/system/memory/memory41/state:offline
    /sys/devices/system/memory/memory42/state:offline
    /sys/devices/system/memory/memory43/state:offline
    ~以下略~
    # <strong>for i in {40..135}; do echo online &gt; \
    /sys/devices/system/memory/memory${i}/state; done</strong>
    # free -m
                 total       used       free     shared    buffers     cached
    Mem:         16234        609      15625          0         12        255
    -/+ buffers/cache:        341      15892
    Swap:            0          0          0

オフラインのメモリを/sys/devices/system/memory/*/stateから確認します。後はonlineに変更するのみです。

●CPUをオンラインに
    # <strong>lscpu</strong>
    Architecture:          x86_64
    CPU op-mode(s):        32-bit, 64-bit
    Byte Order:            Little Endian
    CPU(s):                4
    On-line CPU(s) list:   0
    Off-line CPU(s) list:  1-3
    ~以下略~
    # <strong>for i in {1..3}; do echo 1 &gt; /sys/devices/system/cpu/cpu${i}/online; done</strong>
    # <strong>lscpu</strong>
    Architecture:          x86_64
    CPU op-mode(s):        32-bit, 64-bit
    Byte Order:            Little Endian
    CPU(s):                4
    On-line CPU(s) list:   0-3
    ~以下略~

オフラインのCPUをlscpuを実行しOff-line CPU(s) listから確認します。後はonlineを有効にするのみです。

以上、CPUもメモリも簡単にオンラインにできることが確認できました。 なお、CPUやメモリのオンライン化はudevで管理されているので、自動反映させることも可能です。具体的には以下の設定となります。

 # <strong>vi /etc/udev/rules.d/40-hotadd.rules</strong>
    SUBSYSTEM=="cpu", ACTION=="add", ATTR{online}="1"
    SUBSYSTEM=="memory", ACTION=="add", ATTR{state}="online"

Ubuntuの場合はデフォルトで設定入っていませんので上記2行とも書いてください。 CentOS7.1はmemoryの行だけでよいです。CPUの方はデフォルトで /lib/udev/rules.d/40-redhat.rules に設定されていますので記述不要です。 この設定ファイルを作成後は、リサイズすると自動でオンライン化されます。(OS再起動は不要です)

まとめ

ダイナミックスケールは、2014年10月にIDCFクラウドをリリースしてときから利用できる機能ですが、あまり浸透していなかったので取り上げました。
OSが起動している状態で、簡単にかつサービス影響なくスペックアップできることがわかりました。また、CentOS7.xやUbuntuの場合は、リサイズ後にオンライン化が必要です。一方で、スペックダウンを伴うリサイズは、無停止ではできません。その他、lightタイプから他のタイプに変更できない等ありますのでFAQも併せてご覧ください。今回はCPUとメモリでしたが、次回はディスクの追加をオンラインでやりましょう。これもよく聞かれるので。

サーバーを起動したままディスク追加する

$
0
0

オンラインシリーズ第二回でございます、ソリューションアーキテクトの藤城(@tafujish)です。 前回「サーバーを起動したままスペックアップする」ではIDCFクラウドのサーバーでCPUとメモリをサーバー起動した状態で追加する方法をご紹介しました。

ということで、次はボリューム(ディスク)です。

7月末にDATAディスクの容量拡張(リサイズ)の機能がリリースされたのですが気づかれましたでしょうか。このリサイズ機能は、IDCFクラウドのリリース時に実装するかどうか直前まで奮闘し、困難な実装を乗り越え、何とかAPIでのみ先行で提供した機能になります。現在はAPIだけでなく、ポータル上からも簡単に操作できるようになったので気軽に使っていただきたく、かつサーバーが起動した状態でも容量が増やせるのでその方法を見ていきましょう。

本題に入る前に用語説明ですが、 ROOTディスクは、仮想マシン作成と同時に作成され、OSが入っているディスク領域です。 DATAディスクは、仮想マシンにストレージデバイスとして追加して利用する、2本目3本目…のディスクです。 ボリュームは、これらのディスクの総称です。

ディスク容量を増やしたいときは、

  • DATAディスクの容量を拡張する
  • DATAディスクを追加する

という2つの方法があります。

DATAディスクをオンラインで容量拡張する

では一つ目の方法である容量拡張、つまりリサイズについて説明します。 既に利用中のDATAディスクの容量を拡張するのは簡単で、対象のDATAディスクを選択し、リサイズを実施ください。もちろんサーバーが起動した状態で実施可能です。

Resize

ここでOS上でディスクの容量を見ても増えていないと思います。OS上で追加分を認識させるため、以下のコマンドを実行します。 (DATAディスク /dev/sdb を30GBから60GBにリサイズした例)

●対象のディスクのデバイスIDを確認します(ここでは2:0:1:0)
    [root@localhost ~]# <strong>lsscsi</strong>
    [0:0:0:0]    cd/dvd  NECVMWar VMware IDE CDR00 1.00  /dev/sr0
    [2:0:0:0]    disk    VMware   Virtual disk     1.0   /dev/sda
    [<strong>2:0:1:0</strong>]    disk    VMware   Virtual disk     1.0   /dev/sdb

    ●対象のディスクをリスキャンします
    [root@localhost ~]# <strong>echo 1 &gt; /sys/class/scsi_disk/2\:0\:1\:0/device/rescan</strong>
    [root@localhost ~]# 

    ●ディスクの容量が増えているか確認します
    [root@localhost ~]# <strong>fdisk -l /dev/sdb</strong>

    ディスク /dev/sdb: <strong>64.4 GB</strong>, 64424509440 バイト
    ヘッド 255, セクタ 63, シリンダ 7832
    ~以下略~

OSを再起動せずに拡張した領域を認識させることができました。 iopingで、IOレイテンシーを確認しながら実施しましたが、ポータル上でのリサイズ、OS上でのリスキャンいずれも遅延等の影響なく問題なく追加できました。

この後は/dev/sdb1パーティションを作成していくと思いますが、 パーティション作成後に、パーティションテーブルの読み込みエラーが出ると思います。 こちらもOS再起動せずに認識させることができます。 (ここではfdiskで/dev/sdb2を作成した後の例)

●fdiskでパーティション作成後、以下のエラーが出る
    警告: パーティションテーブルの再読込みがエラー 16 で失敗しました: デバイスもしくはリソースがビジー状態です。
    カーネルはまだ古いテーブルを使っています。新しいテーブルは
    次回リブート時か、partprobe(8)またはkpartx(8)を実行した後に
    使えるようになるでしょう

    ●パーティションテーブルを再読み込み
    [root@localhost ~]# <strong>partx -v -a /dev/sdb</strong>
    device /dev/sdb: start 0 size 125829120
    gpt: 0 slices
    dos: 4 slices
    # 1:        63- 62910539 ( 62910477 sectors,  32210 MB)
    # 2:  62910540-125821079 ( 62910540 sectors,  32210 MB)
    # 3:         0-       -1 (        0 sectors,      0 MB)
    # 4:         0-       -1 (        0 sectors,      0 MB)
    BLKPG: Device or resource busy
    error adding partition 1
    <strong>added partition 2</strong>

    ●パーティションがエラーなく表示されることを確認
    [root@localhost ~]# <strong>fdisk -l /dev/sdb</strong>
    ~以上略~
    デバイス ブート      始点        終点     ブロック   Id  システム
    /dev/sdb1               1        3916    31455238+  8e  Linux LVM
    <strong>/dev/sdb2            3917        7832    31455270   8e  Linux LVM</strong>

以上のように、リサイズからOS上での操作まで一貫して再起動なしでできました。

DATAディスクをオンラインで追加する

では二つ目の方法である、ディスク追加について説明します。 DATAディスクをリサイズして拡張していったとしても、プライマリパーティション数の上限やDATAディスクの容量上限(1TB)にぶち当たることもあるでしょう。そんなときは、DATAディスクを3本目4本目と追加していってください。このDATAディスクの追加も、もちろん再起動なしで利用可能です。

DATAディスクの作成とアタッチはFAQをご覧いただくとして、もちろんこの操作もサーバーが起動した状態で実施いただけます。

ここでOS上でデバイス一覧を見ても、ディスクデバイスは増えていないと思います。OS上で追加分を認識させるため、以下のコマンドを実行します。 (50GBのDATAディスク /dev/sdc を追加した例)

●対象のHBA番号を確認します(ここでは2)
    [root@localhost ~]# <strong>lsscsi</strong>
    [0:0:0:0]    cd/dvd  NECVMWar VMware IDE CDR00 1.00  /dev/sr0
    [2:0:0:0]    disk    VMware   Virtual disk     1.0   /dev/sda
    [<strong>2</strong>:0:1:0]    disk    VMware   Virtual disk     1.0   /dev/sdb

    ●対象のHBAをリスキャンします
    [root@localhost ~]# <strong>echo "- - -" &gt; /sys/class/scsi_host/host2/scan</strong>
    [root@localhost ~]#

    ●新しいディスク(/dev/sdc)が増えているか確認します
    [root@localhost ~]# <strong>fdisk -l /dev/sdc</strong>

    ディスク <strong>/dev/sdc</strong>: 53.7 GB, 53687091200 バイト
    ヘッド 255, セクタ 63, シリンダ 6527
    ~以下略~

OSを再起動せずに追加したDATAディスクを認識させることができました。先ほどと同じくiopingで、IOレイテンシーを確認しながら実施しましたが、ポータル上でのアタッチ、OS上でのリスキャンいずれも遅延等の影響なく問題なく追加できました。 こちらの方が簡単ですね。

容量スケールするディスク、どう使う?

ここまでは、ディスクやその容量を増やす方法とパーティション作成を紹介しました。 実際の問題として、サーバーを止めずに実使用量を増やすとなると、予めLVM(Logical Volume Manager)で構成しておく必要があります。はじめにDATAディスク上にLVMで構成しておくと、リサイズでもディスク追加でも無停止で容量を増やすことが可能です。この手順は長くなるので、一番最後のパートで紹介します。

次に、容量を増やしたいと思ったとき、リサイズとディスク追加どちらを選ぶか問題です。

基本的にはディスク追加の方がおすすめで、以下の理由があります。

  • ディスクを束ねて1TB以上の容量が構成可能
  • 将来、容量が不要になった時に追加分のディスクを削除可能

一方でリサイズでなければならない理由としては、

  • IDCFクラウドのスナップショット機能を利用している

場合は、1つのディスク毎でしかスナップショットが取れないためでリサイズが有効です。どうしても複数ディスクでスナップショットを取りたい場合は今々だとLVMスナップショットを使ってOS上で実施するしか手がないです。

まとめ

では、先にまとめで前回今回と、サーバーを起動したままCPU、メモリ、ディスクを増やすことができることを見てきました。取り上げませんでしたが、NICの追加も可能です。 リサイズでもディスク追加でも、実施後にOS上で追加分を認識させることが必要で、これをオンラインでできるので、サーバー再起動は一切ありませんでした。認識させるのもコマンド一発なので簡単に実施可能でした。 以降では、LVMを構成し、容量を追加していく、実際の流れを見ていきます。オンラインでのディスク追加に興味を持たれた方は、参考にしてください。

[実戦]LVMを使って容量を増やしていこう

では、以下の流れでディスクを拡張していきます。 1) DATAディスク上でLVMを構成する 2) DATAディスクをリサイズし、LVM領域を拡張する 3) DATAディスクを追加し、LVM領域を拡張する

1) DATAディスク上でLVMを構成する

LVM_1st_stepまずは、上図のとおり30GBのDATAディスクがあるサーバーで、LVM構成を構築します。

●パーティションを作成します
    [root@localhost ~]# <strong>fdisk /dev/sdb</strong>
    デバイスは正常な DOS 領域テーブルも、Sun, SGI や OSF ディスクラベルも
    含んでいません
    新たに DOS ディスクラベルをディスク識別子 0x3b57b701 で作成します。
    あなたが書き込みを決定するまで、変更はメモリ内だけに残します。
    その後はもちろん以前の内容は修復不可能になります。
    警告: 領域テーブル 4 の不正なフラグ 0x0000 は w(書き込み)によって
    正常になります

    警告: DOS互換モードは廃止予定です。このモード (コマンド'c') を止めることを
          強く推奨します。 and change display units to
             sectors (command 'u').

    コマンド (m でヘルプ): <strong>n</strong>
    コマンドアクション
       e   拡張
       p   基本パーティション (1-4)
    p
    パーティション番号 (1-4): <strong>1</strong>
    最初 シリンダ (1-3916, 初期値 1):
    初期値 1 を使います
    Last シリンダ, +シリンダ数 or +size{K,M,G} (1-3916, 初期値 3916):
    初期値 3916 を使います

    コマンド (m でヘルプ): <strong>t</strong>
    選択した領域 1
    16進数コード (L コマンドでコードリスト表示): <strong>8e</strong>
    領域のシステムタイプを 1 から 8e (Linux LVM) に変更しました

    コマンド (m でヘルプ): <strong>p</strong>

    ディスク /dev/sdb: 32.2 GB, 32212254720 バイト
    ヘッド 255, セクタ 63, シリンダ 3916
    Units = シリンダ数 of 16065 * 512 = 8225280 バイト
    セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    ディスク識別子: 0x3b57b701

    デバイス ブート      始点        終点     ブロック   Id  システム
    <strong>/dev/sdb1               1        3916    31455238+  8e  Linux LVM</strong>

    コマンド (m でヘルプ): <strong>w</strong>
    パーティションテーブルは変更されました!

    ioctl() を呼び出してパーティションテーブルを再読込みします。
    ディスクを同期しています。
    [root@localhost ~]# <strong>fdisk -l /dev/sdb</strong>

    ディスク /dev/sdb: 32.2 GB, 32212254720 バイト
    ヘッド 255, セクタ 63, シリンダ 3916
    Units = シリンダ数 of 16065 * 512 = 8225280 バイト
    セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    ディスク識別子: 0x3b57b701

    デバイス ブート      始点        終点     ブロック   Id  システム
    <strong>/dev/sdb1               1        3916    31455238+  8e  Linux LVM</strong>

    ●物理ボリュームを作成し、確認します
    [root@localhost ~]# <strong>pvcreate /dev/sdb1</strong>
      Physical volume "/dev/sdb1" successfully created
    [root@localhost ~]# <strong>pvdisplay</strong>
      "/dev/sdb1" is a new physical volume of "30.00 GiB"
      --- NEW Physical volume ---
      PV Name               <strong>/dev/sdb1</strong>
      VG Name
      PV Size               30.00 GiB
      Allocatable           NO
      PE Size               0
      Total PE              0
      Free PE               0
      Allocated PE          0
      PV UUID               37mk1N-kWrH-6XfL-ws8J-1CxG-q8yB-LM1pIw

    ●ボリュームグループを作成し、確認します
    [root@localhost ~]# <strong>vgcreate VG01 /dev/sdb1</strong>
      Volume group "VG01" successfully created
    [root@localhost ~]# <strong>vgdisplay</strong>
      --- Volume group ---
      VG Name               <strong>VG01</strong>
      System ID
      Format                lvm2
      Metadata Areas        1
      Metadata Sequence No  1
      VG Access             read/write
      VG Status             resizable
      MAX LV                0
      Cur LV                0
      Open LV               0
      Max PV                0
      Cur PV                1
      Act PV                1
      VG Size               30.00 GiB
      PE Size               4.00 MiB
      Total PE              7679
      Alloc PE / Size       0 / 0
      Free  PE / Size       7679 / 30.00 GiB
      VG UUID               F9piza-DPvp-Gme1-aKc9-vuM0-HQZH-v2LVry

    ●論理ボリュームを作成し、確認します
    [root@localhost ~]# <strong>lvcreate -l 100%FREE -n LV01 VG01</strong>
      Logical volume "LV01" created
    [root@localhost ~]# <strong>lvdisplay</strong>
      --- Logical volume ---
      LV Path                <strong>/dev/VG01/LV01</strong>
      LV Name                LV01
      VG Name                VG01
      LV UUID                z5s6Md-7b2x-yhAP-YF36-zOip-y8aS-dnxhj7
      LV Write Access        read/write
      LV Creation host, time localhost.cs18idcfcloud.internal, 2015-09-08 13:46:12 +0900
      LV Status              available
      # open                 0
      LV Size                30.00 GiB
      Current LE             7679
      Segments               1
      Allocation             inherit
      Read ahead sectors     auto
      - currently set to     256
      Block device           253:0

    ●ext4でフォーマットしマウントします
    [root@localhost ~]# <strong>mkfs.ext4 /dev/VG01/LV01</strong>
    mke2fs 1.41.12 (17-May-2010)
    Filesystem label=
    OS type: Linux
    Block size=4096 (log=2)
    Fragment size=4096 (log=2)
    Stride=0 blocks, Stripe width=0 blocks
    1966080 inodes, 7863296 blocks
    393164 blocks (5.00%) reserved for the super user
    First data block=0
    Maximum filesystem blocks=4294967296
    240 block groups
    32768 blocks per group, 32768 fragments per group
    8192 inodes per group
    Superblock backups stored on blocks:
            32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
            4096000

    Writing inode tables: done
    Creating journal (32768 blocks): done
    Writing superblocks and filesystem accounting information: done

    This filesystem will be automatically checked every 20 mounts or
    180 days, whichever comes first.  Use tune2fs -c or -i to override.
    [root@localhost ~]# <strong>mkdir /data</strong>
    [root@localhost ~]# <strong>mount /dev/VG01/LV01 /data</strong>
    [root@localhost ~]# <strong>df -h</strong>
    Filesystem            Size  Used Avail Use% Mounted on
    /dev/sda1              15G  976M   13G   7% /
    tmpfs                 1.9G     0  1.9G   0% /dev/shm
    /dev/mapper/VG01-LV01
                           <strong>30G</strong>   44M   28G   1% /data
    [root@localhost ~]#

2) データディスクをリサイズし、LVM領域を拡張する

LVM_2nd_step次にリサイズによる容量拡張です。 ポータル上で30GBのDATAディスクを60GBにリサイズします。 その後、上図のとおりリサイズしたDATAディスクを使って、LVM領域を拡張します。

●リサイズしたディスク領域を認識させます
    [root@localhost ~]# <strong>lsscsi | grep /dev/sdb</strong>
    [<strong>2:0:1:0</strong>]    disk    VMware   Virtual disk     1.0   /dev/sdb
    [root@localhost ~]# <strong>echo 1 &gt; /sys/class/scsi_disk/2\:0\:1\:0/device/rescan</strong>
    [root@localhost ~]#

    ●拡張してできた空き領域にパーティションを作成し、認識させます
    [root@localhost ~]# <strong>fdisk /dev/sdb</strong>

    警告: DOS互換モードは廃止予定です。このモード (コマンド 'c') を止めることを
          強く推奨します。 and change display units to
             sectors (command 'u').

    コマンド (m でヘルプ): <strong>n</strong>
    コマンドアクション
       e   拡張
       p   基本パーティション (1-4)
    p
    パーティション番号 (1-4): <strong>2</strong>
    最初 シリンダ (3917-7832, 初期値 3917):
    初期値 3917 を使います
    Last シリンダ, +シリンダ数 or +size{K,M,G} (3917-7832, 初期値 7832):
    初期値 7832 を使います

    コマンド (m でヘルプ): <strong>t</strong>
    パーティション番号 (1-4): <strong>2</strong>
    16進数コード (L コマンドでコードリスト表示): <strong>8e</strong>
    領域のシステムタイプを 83 から 8e (Linux LVM) に変更しました

    コマンド (m でヘルプ): <strong>p</strong>

    ディスク /dev/sdb: 64.4 GB, 64424509440 バイト
    ヘッド 255, セクタ 63, シリンダ 7832
    Units = シリンダ数 of 16065 * 512 = 8225280 バイト
    セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    ディスク識別子: 0x3b57b701

    デバイス ブート      始点        終点     ブロック   Id  システム
    /dev/sdb1               1        3916    31455238+  8e  Linux LVM
    <strong>/dev/sdb2            3917        7832    31455270   8e  Linux LVM</strong>

    コマンド (m でヘルプ): <strong>w</strong>
    パーティションテーブルは変更されました!

    ioctl() を呼び出してパーティションテーブルを再読込みします。

    警告: パーティションテーブルの再読込みがエラー 16 で失敗しました: デバイスもしくはリソースがビジー状態です。
    カーネルはまだ古いテーブルを使っています。新しいテーブルは
    次回リブート時か、partprobe(8)またはkpartx(8)を実行した後に
    使えるようになるでしょう
    ディスクを同期しています。
    [root@localhost ~]# <strong>partx -l /dev/sdb</strong>
    # 1:        63- 62910539 ( 62910477 sectors,  32210 MB)
    <strong># 2:  62910540-125821079 ( 62910540 sectors,  32210 MB)</strong>
    # 3:         0-       -1 (        0 sectors,      0 MB)
    # 4:         0-       -1 (        0 sectors,      0 MB)
    [root@localhost ~]# <strong>partx -v -a /dev/sdb</strong>
    device /dev/sdb: start 0 size 125829120
    gpt: 0 slices
    dos: 4 slices
    # 1:        63- 62910539 ( 62910477 sectors,  32210 MB)
    # 2:  62910540-125821079 ( 62910540 sectors,  32210 MB)
    # 3:         0-       -1 (        0 sectors,      0 MB)
    # 4:         0-       -1 (        0 sectors,      0 MB)
    BLKPG: Device or resource busy
    error adding partition 1
    <strong>added partition 2</strong>

    ●追加したパーティションを物理ボリュームにします
    [root@localhost ~]# <strong>pvcreate /dev/sdb2</strong>
      Physical volume "/dev/sdb2" successfully created

    ●既存のボリュームグループに追加した物理ボリュームを追加します
    [root@localhost ~]# <strong>vgextend VG01 /dev/sdb2</strong>
      Volume group "VG01" successfully extended

    ●既存の論理ボリュームを拡張します
    [root@localhost ~]# <strong>lvextend -l +100%FREE /dev/VG01/LV01</strong>
      Size of logical volume VG01/LV01 changed from 30.00 GiB (7679 extents) to 59.99 GiB (15358 extents).
      Logical volume LV01 successfully resized
    [root@localhost ~]# <strong>lvdisplay</strong>
      --- Logical volume ---
      LV Path                /dev/VG01/LV01
      LV Name                LV01
      VG Name                VG01
      LV UUID                z5s6Md-7b2x-yhAP-YF36-zOip-y8aS-dnxhj7
      LV Write Access        read/write
      LV Creation host, time localhost.cs18idcfcloud.internal, 2015-09-08 13:46:12 +0900
      LV Status              available
      # open                 1
      LV Size                <strong>59.99 GiB</strong>
      Current LE             15358
      Segments               2
      Allocation             inherit
      Read ahead sectors     auto
      - currently set to     256
      Block device           253:0

    ●ファイルシステムを拡張し、これで拡張分の容量が使えるようになりました
    [root@localhost ~]# <strong>resize2fs /dev/VG01/LV01</strong>
    resize2fs 1.41.12 (17-May-2010)
    Filesystem at /dev/VG01/LV01 is mounted on /data; on-line resizing required
    old desc_blocks = 2, new_desc_blocks = 4
    Performing an on-line resize of /dev/VG01/LV01 to 15726592 (4k) blocks.
    The filesystem on /dev/VG01/LV01 is now 15726592 blocks long.

    [root@localhost ~]# df -h
    Filesystem            Size  Used Avail Use% Mounted on
    /dev/sda1              15G  976M   13G   7% /
    tmpfs                 1.9G     0  1.9G   0% /dev/shm
    /dev/mapper/VG01-LV01
                           <strong>59G</strong>   52M   56G   1% /data
    [root@localhost ~]#

3) データディスクを追加し、LVM領域を拡張する

LVM_3rd_step最後にディスク追加です。 ポータル上で50GBのDATAディスク作成しアタッチします。 その後、上図のとおり追加したDATAディスクを使って、LVM領域を拡張します。

●追加したディスクを認識させます
    [root@localhost ~]# lsscsi | grep /dev/sd
    [<strong>2</strong>:0:0:0]    disk    VMware   Virtual disk     1.0   /dev/sda
    [<strong>2</strong>:0:1:0]    disk    VMware   Virtual disk     1.0   /dev/sdb
    [root@localhost ~]# <strong> echo "- - -" &gt; /sys/class/scsi_host/host2/scan</strong> 
    [root@localhost ~]#

    ●追加したディスクにパーティションを作成します
    [root@localhost ~]# <strong>fdisk /dev/sdc</strong>
    デバイスは正常な DOS 領域テーブルも、Sun, SGI や OSF ディスクラベルも
    含んでいません
    新たに DOS ディスクラベルをディスク識別子 0x191aee31 で作成します。
    あなたが書き込みを決定するまで、変更はメモリ内だけに残します。
    その後はもちろん以前の内容は修復不可能になります。
    警告: 領域テーブル 4 の不正なフラグ 0x0000 は w(書き込み)によって
    正常になります

    警告: DOS互換モードは廃止予定です。このモード (コマンド'c') を止めることを
          強く推奨します。 and change display units to
             sectors (command 'u').

    コマンド (m でヘルプ): <strong>n</strong>
    コマンドアクション
       e   拡張
       p   基本パーティション (1-4)
    p
    パーティション番号 (1-4): <strong>1</strong>
    最初 シリンダ (1-6527, 初期値 1):
    初期値 1 を使います
    Last シリンダ, +シリンダ数 or +size{K,M,G} (1-6527, 初期値 6527):
    初期値 6527 を使います

    コマンド (m でヘルプ): <strong>t</strong>
    選択した領域 1
    16進数コード (L コマンドでコードリスト表示): <strong>8e</strong>
    領域のシステムタイプを 1 から 8e (Linux LVM) に変更しました

    コマンド (m でヘルプ): <strong>p</strong>

    ディスク /dev/sdc: 53.7 GB, 53687091200 バイト
    ヘッド 255, セクタ 63, シリンダ 6527
    Units = シリンダ数 of 16065 * 512 = 8225280 バイト
    セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    ディスク識別子: 0x191aee31

    デバイス ブート      始点        終点     ブロック   Id  システム
    <strong>/dev/sdc1               1        6527    52428096   8e  Linux LVM</strong>

    コマンド (m でヘルプ): <strong>w</strong>
    パーティションテーブルは変更されました!

    ioctl() を呼び出してパーティションテーブルを再読込みします。
    ディスクを同期しています。
    [root@localhost ~]# <strong>fdisk -l /dev/sdc</strong>

    ディスク /dev/sdc: 53.7 GB, 53687091200 バイト
    ヘッド 255, セクタ 63, シリンダ 6527
    Units = シリンダ数 of 16065 * 512 = 8225280 バイト
    セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    ディスク識別子: 0x191aee31

    デバイス ブート      始点        終点     ブロック   Id  システム
    <strong>/dev/sdc1               1        6527    52428096   8e  Linux LVM</strong>

    ●追加したパーティションを物理ボリュームにします
    [root@localhost ~]# <strong>pvcreate /dev/sdc1</strong>
      Physical volume "/dev/sdc1" successfully created

    ●既存のボリュームグループに追加した物理ボリュームを追加します
    [root@localhost ~]# <strong>vgextend VG01 /dev/sdc1</strong>
      Volume group "VG01" successfully extended

    ●既存の論理ボリュームを拡張します
    [root@localhost ~]# <strong>lvextend -l +100%FREE /dev/VG01/LV01</strong>
      Size of logical volume VG01/LV01 changed from 59.99 GiB (15358 extents) to 109.99 GiB (28157 extents).
      Logical volume LV01 successfully resized

    ●ファイルシステムを拡張し、これで拡張分の容量が使えるようになりました
    [root@localhost ~]# <strong>resize2fs /dev/VG01/LV01</strong>
    resize2fs 1.41.12 (17-May-2010)
    Filesystem at /dev/VG01/LV01 is mounted on /data; on-line resizing required
    old desc_blocks = 4, new_desc_blocks = 7
    Performing an on-line resize of /dev/VG01/LV01 to 28832768 (4k) blocks.
    The filesystem on /dev/VG01/LV01 is now 28832768 blocks long.

    [root@localhost ~]# <strong>df -h</strong>
    Filesystem            Size  Used Avail Use% Mounted on
    /dev/sda1              15G  976M   13G   7% /
    tmpfs                 1.9G     0  1.9G   0% /dev/shm
    /dev/mapper/VG01-LV01
                          <strong>109G</strong>   60M  103G   1% /data
    [root@localhost ~]#

以上です、最後までご覧いただきありがとうございました。お疲れ様でした。

5分で疑似体験!ITエンジニアが自作IoTデバイス制作に初チャレンジ!

$
0
0

スイッチサイエンス myThingsをはじめようキット
IoT元年と言われる昨年から今年にかけ、IoT関連の製品・サービスのリリースでにぎわっています。ハードウェア・スタートアップも増え、俄然、自作デバイス(電子工作)がカジュアルな雰囲気を醸し出し、興味をお持ちの読者の方もいらっしゃるのではないでしょうか?

※IDCFクラウドも御多分に洩れず、7月に、ヤフーが提供する「myThings」に自作デバイスを接続できる「IDCF」チャンネルを公開。文頭の写真は、スイッチサイエンス社が販売する「myThingsをはじめようキット」。

今回のエンジニアブログでは、自作IoTデバイス制作に初挑戦したITエンジニアの方へのインタビューを敢行!その時何が起こったのか、つまびらかにしたいと思います。これからチャレンジしよう!というみなさまのヒントになれば幸いです。

ライティングを担当するのは、非エンジニアのサービスディベロップメントグループ渡邉です。気がつけば、インタビュー2割、主観8割の記事になっておりましたので、ぜひ感想やご意見をお寄せいただければ幸いです。(@idcfrontier)

[序章]

・主役

今回インタビューに応じてくださったのは、Webシステム開発を手がける株式会社ドロップシステムの代表取締役社長の大井航平さんです(写真左・写真右はインタビュアーのR&D室長 大屋誠)。

大井さんと大屋さn

大井さんは社長の肩書きをお持ちですが、コードをガリガリ書く現役のエンジニアさんでもいらっしゃいます。アプリやサーバーサイドの開発を手がけられ、腕にはスマートウォッチが光るガジェット好きです。

・経緯

大井さんはこれまで電子工作未経験でしたが、同僚にM2M関連のビジネスを手がけ、ハードウェアを自作している開発者がいらっしゃるため、ずっと自作IoTの分野が気になっていたそう。「今度のイベントで、myThingsについて発表しようかな…」と発言したが最後、しばらくしてIDCFから、「myThingsをはじめようキット」が、「レンタル」と大きく書かれて送りつけられてきました。特に手がかりもなく、これで「やってみた」的な発表をする状況に追い込まれてしまった大井さん。無情にも闘いのゴングが鳴り響きます…!

[Round 1 電子工作の世界へようこそ!]

・電子工作のお作法がわからない…

開発者でガジェット好きな大井さんでも、「myThingsをはじめようキット」を目に前に、悩んだそうです。「myThingsをはじめようキット」には、Rassbery Piと各種センサーなど電子工作に必要なハードウェア、パーツが一通り揃っています。が、ウェブ系の開発者には、何をどうするのかお作法がわかりません。

悩み抜いた末、まずはRassbery Piに関する本を読んだとのこと。

これは、自作IoTデバイス界隈ではよく耳にするお話!ハードウェア、プログラム、サーバー、それぞれの知識が必要になるIoT分野は、いずれのジャンルのエンジニアにとっても、新しい分野の勉強が必要になるといいます。だからこそ、この世界が輝きを持って、エンジニアの心を捉えて止まないのかもしれません…!

さて、電子工作のお作法を本で学んだ大井さんは、パーツを知り合いから借りたり、通販で購入したりします。電子工作のパーツ、というと、私のような素人には、秋葉原あたりでしか売っていないのでは?と思ってしまいますが、イマドキは大手通販サイトでも、各種センサー類などが簡単に手に入るのだそうですよ。

→とっかかりは、本を読みましょう!

・Lチカ、だけじゃない!Rassbery Piでここまで遊べる!

教本とパーツを手にした大井さん、Rassbery Piとさまざまなハードウェアを組み合わせ、とことん遊び尽くします。大井さんのチャレンジの”一部"は下記の通り!お写真は、大井さんにお借りしました。

超音波測距

測距超音波距離センサモジュールを使って超音波で距離を測ることができます。2つの突起部分の片方はスピーカー、片方はマイクとなっています。スピーカー側から出た音が、物体に当たって跳ね返り、マイク側が拾います。受信するまでの時間に、音速をかけると、距離が出る、というわけです。

LCD

LCD LCDは何の略かというと、liquid crystal display…はい、「液晶ディスプレイ」です。身近な液晶ディスプレイですが、おや…?こちらは、ケーブルの口がありません。なんと、Rassbery Piとピンで直挿しです。信号を制御するプログラムを書き、コンパイルする事で、初めて文字が出力されます。「コンパイル」って、新鮮な響き…!

PWM

PWM Pulse Width Modulationの略です。パルス幅変調。パルス幅を変調させて、何をするのか?そう!これが言わずと知れた「Lチカ」です!一定周波数のパルスで、LEDをオン・オフさせてチカチカさせます。単位あたりの点灯時間を調整し、人の目から見た明るさも変えることができます。「無駄に遊べる」とは大井さんの弁。Lチカ、とっても楽しいようです!

Hover

HOVER

簡単なハンドジェスチャーを認識するセンサーです。指でのジェスチャーやタッチ操作を、電気信号に変えて、Rassbery Piで計測・測定します。大井さんによれば、Hoverでドラムプレイをするデモがあったとか!人の動きのセンサーというと私たちにはKinectなどが身近ですが、Hoverはシングルボードコンピューターでライトに利用できるのがいいですね。

臭気センサー

臭気センサー
おならを計測しようと、意気揚々とRassbery Piに、臭気センサーを接続した大井さん。しかしながら、ご友人からもらったこの機種は、高い精度でにおいを測定しようというもの。おならであっても、正確にパルスを発生させて数msで計測しようとするため、とてもRassbery Piの手に負えませんでした。「もっと簡単なセンサーもあるみたい」と大井さん。「いままでで一番すごい屁のランキングを作りたい」と志を貫くべく、継続して情報収集中です。

温湿度気圧計

温室度センサー
温室度気圧計、そう、myThingsをはじめようキットにも入っているんですよね…myThings…って、大井さん!myThingsの話はどこにいったんですか!?

ここまでIDCFクラウドの仮想マシンを「無駄に課金させていた」と白状した大井さん。上記以外にも、さまざまなセンサー、パーツをRassbery Piにつなげていたそうです。さあ、そろそろmyThingsをはじめましょう!

→電子工作って、相当楽しいみたい!

[Round2 インターネットの壁]

電子工作の世界を思うがままに楽しんだ大井さん。ウェブ系の開発者ですから、ここからが本領発揮!さまざまなツールと電子工作を連携させたプログラミングをしようと、「IDCF」チャンネルを通じて、myThingsにつないでいきます。

img_iot_connect

難なくmyThingsに ログインし、IDCFクラウドもさっと立ち上げ、「IDCF」チャンネルの認証を早々に済ませます。このあたりのセキュリティを考慮したポートの設定はお 手の物…!

ポート

(引用:大井さん発表資料)

しかし、ウェブ系の開発者の大井さんであっても、一筋縄ではいかないポイントがありました。

・ドキュメントの言葉がわからない

「IDCF」チャンネルの公式ドキュメントを読み始めた大井さんですが…

ウェブ「『トリガー』って何?『発火』とは!?」これは新IT用語の基礎知識でしょうか、ドキュメントの言葉がさっぱり頭に入ってきません…!「IDCF」チャンネルのページを目を皿のようにして探しても、答えは見つかりません…。 そこで開発者の大井さんは、Githubで公開されている「IDCF」チャンネルのソースコードを解読しはじめます。処理をフロー図に起こした上で、「『トリガー』ってこういうこと…!『発火』ってPushのこと!」と理解した上で、プログラムを進めることとなります。

ドキュメントが頭に入ってこない…というのは、はじめての自作IoTデバイス制作のチャレンジにおいては、①新しいジャンルなので言葉が定まっていない、②自分の分野外の言葉に触れる必要がある、ため往々にしてあることなのかもしれません。IDCFの制作側も「さまざまな専門分野の読者がいることを意識せねば…」と反省し、ドキュメントを修正したのでした。

・ブラックボックスの功罪

「IDCF」チャンネルは、ユーザーの方にサーバーサイドの動作を意識させず手軽に使えるよう、Dockerコンテナに必要な機能をまとめています。が、ウェブ系の開発者の大井さんは「自分の考えていることが実現できるのかわからない」と、時間のゆるす限り、ソースコードを読み、プログラムを実行し、どういう処理が帰ってくるか確認を進めるのです。

大井さんのテスト1ふむふむ〆(._.)

大井さんのテスト2((φ( ̄Д ̄ )ホォホォ

大井さんのテスト3φ(▼ー▼キ) メモメモ

検証は続きます。時間をかけ、丁寧に仕様を解読する大井さん。ブラックボックスにしたツールは、専門外のユーザーには使い勝手がよい反面、専門知識があるユーザーにはカスタマイズが効かないので面白味が半減しまうようです。

しかし、時間は有限です。発表の日が目前に迫り、とりあえず公式ドキュメントのサンプルコードを実行。温室度センサーのデータをMQTTで「IDCF」チャンネルに送信し myThings経由で、slackに投げたところまで動作確認を終えた大井さん。「時間がなかった」と消化不良のご様子。

モノがインターネットにつながることを「体験」するだけならやりやすいのですが、自分の構想を実現しようとすると、

①自分の専門外の分野のインプットする、②仕様を解きほぐしながら進める、ため、どうしても一定の時間は必要になりそうです。

→どっぷり取り組む時間が確保できたら幸せ!

[まとめ - 余暇の時間でIoTに取り組むには?]

大井さんへのインタビューを終えて感じたことは、電子工作は歴史があり比較的初心者でもカジュアルに楽しめるものの、インターネットにつなごうとするとまだ情報が少なく試行錯誤が必要である、ということです。個人が貴重な休みの時間をつかって「IoT」に取り組むとしたらどうしたらいいのでしょう?

それは、近年、国内外で成功を収めるハードウェア・スタートアップに学ぶところがありそうです。彼らの勝因は、圧倒的なスピー ド感!大手メーカーが不可能なスピード感で開発を進めることで、研究開発費を大幅に圧縮し、数千ロットの生産で投資を回収できる。そこにスタートアップは大手に勝てるニッチな市場を見いだします。 彼らは専門外のパートナーを見つけることに長けていると同時に、ハードもアプリもサーバーも、既存のツールをうまく組み合わせて開発を省力化します。

しかし、ツールを使うにあたり、現状、個人ユーザーが、日本語で情報を探すのはなかなか困難な模様です。英語であれば、海外はIoTの分野が数年進んでいますから、情報量は格段に増えます。英語が得意な方は、ぜひ海外のサイトにあたってみてください。

日本でも、自作IoTデバイスにチャレンジする人が増えています。相互の情報共有を進めることで、今後、敷居はさがっていくでしょう。「自作デバイスをmyThingsにつなごう」というFacebookグループもありますので、ぜひ参加してください。読者のみなさんが、Facebookグループで専門外のパートナーを見つけて、ハードウェアで起業する、なんて展開を夢見ています!

[参考サイト]

興味をもたれたエンジニアの方に、日本語で自作IoTデバイス制作の情報が得られるサイトをご紹介します。

「スイッチサイエンス」 https://www.switch-science.com/電子工作用の電子部品を扱う通販サイト。海外サイトの日本語訳をブログで配信したり、はんだづけカフェの運営など、意欲的に日本の電子工作人口を広めています。「myThingsをはじめようキット」の販売も。

「Make: Japan」 http://makezine.jp/出版社のオライリーが運営するサイト。電子工作に関するニュースや、利用例などを、ほぼ日次で配信しています。

「Device Plus」 http://deviceplus.jp/半導体メーカーのロームが運営するサイト。電子工作やエンジニアライフにまつわるネタ、ニュース、イベント情報などが配信されています。

「MONOist」 http://monoist.atmarkit.co.jp/アイティメディアが運営する組み込み系に特化したニュースを配信するサイト。産業材向けのニュースが多い中、「ラズパイ2で遊ぼうぜ」「電子工作“超”入門」といった連載があります。

「TechCrunch」 http://jp.techcrunch.com/ガジェット/テクノロジーメディアのTechCrunchも、ガジェッド系のニュースが増えてきています。「ガジェット」タグの記事が数日に一度更新され、最新のツールや組み合わせアイデアなどを得ることができます。

※本記事は、ユーザーの方へのインタビューおよびIDCFクラウドMeetupでの発表資料をもとに、ライターの全面的な主観で再構成し、大幅に加筆したものです。

(取材日:2015年9月4日)

サービスディベロップメント
ライター紹介:サービスディベロップメントグループ 渡邉 IoT大好き!だけどLチカはできません! 流行モノが変わるたびにプロフィールの「趣味」欄が変わるアイドルに憧れ、それを愚直に実践しています。
Viewing all 122 articles
Browse latest View live