2013年11月11日月曜日

メールサーバー移行失敗

経緯

サーバー解約に伴ってメールサーバーも移転する必要があったが、メールサーバーの運用はかなり手間ということをこれまでの経験で学んだのでメールだけをさくらメールボックスに移転することに決めた。
ちなみにメール送受信で使うドメインはexample.comのようにPOP(IMAP)もSMTPもWebで使っているドメインと同一である。

さくらメールボックス

費用:1000円/年間
容量:10GB
独自ドメイン:可


月80円程度でコスパ最強のメールボックスではないだろうか。


移転計画


  1. 予めMXレコードのTTLを短くしておく
  2. さくらメールボックスに既存のユーザーと同じパスワードを設定しておく
  3. 数日後、MXレコードを変更する

完璧\(^o^)/

メールが受信できない事件

移行計画の1と2を実行し翌週にMXレコードを以下のように書き換えた。

example.com MX example.com



example.com MX さくらメールボックスIP

$dig example.com mx
で変更されている確認。

ついでにGoogleさんにも聞いておく。

$dig @8.8.8.8 example.com mx

確認

  1. [email protected]
  2. [email protected]
2は直ぐに届いたが1が一向にメーラーで受信できない。


さくらメールボックスをWebメールから確認してみると問題なく届いてる。


なぜ…?


原因



POP(IMAP)のDNSレコード参照はMXではない!!!

完全に見落としてた!!!!!

受信しても移行前のサーバーのメールサーバーを参照しており、まったく受信できないのは当たり前。

これを解決するにはexample.comのAレコードをさくらメールボックスに向ける必要があるのだがそこにはWebサーバーはないのでAレコードを切り替えた途端にWebへのアクセスが不可になる。


POPのドメインを変えるしか方法はない。

mail.example.comを作成しさくらメールボックスに向けて、受信サーバーをmail.example.comに変更することで解決。

WordPressからのメールが移行前のSMTPを使ってる&SPAMになる事件


移行後、Wordpressから送信されるメールがGmailの迷惑メールに入るようになってしまった。

メールサーバー移行時にSPFレコードもさくらメールボックスに設定したのになぜ?

原因


WordpressがSMTPをlocalhostを設定していた!!

これも見落としてた。。。

SPFレコードと異なるSMTPから送信されているのでついでにSPAM扱いされておりました。

解決方法としては

  1. PHPのPearでSMTP Authに対応させPHPからのメールを全てさくらメールボックスにリレーする方法。http://stackoverflow.com/questions/112190/php-ini-smtp-how-do-you-pass-username-password
  2. WP SMTPプラグインを入れる方法。http://wordpress.org/plugins/wp-mail-smtp/

このサーバーには複数のサービスが動いておりPHPの環境を変えるのにはリスクがあったので2を選んだ。



この作業でやっとこさメールサーバーを移行出来ました。。。




2013年10月27日日曜日

クラウドゲーミングのサーバープラットフォームについてのメモ

調べたのでメモ

NVIDIA一択

クラウドゲーミングをエンタープライズレベルで運用するには次の3点に絞られると思う。
  1. 自社で運用できるHypervisor(Vmware、Xen、Hyper-V)などで運用する
  2. AWSで運用する
  3. 既存のクラウドゲーミングプラットフォームプロバイダを使う
まず、この3点どれをとってもNVIDIAの選択以外になさそう。GPUを出している半導体メーカが多くなく、クライアント向けからGPGPUも実現できるほど幅広いソリューションがあるのでNVIDIAのベンダーロックインはあまり問題になることはないと思う。


自社運用の選択

サーバーの自社運用は取り回しのしやすさがあるので金額次第では捨てることができないカード。

サーバーアプライアンス


NVIDIA GRID VCA(Visual Computing Appliance)の仮想環境からグラフィックカード、NASまで搭載されいるのでとりあえずこれを1台買えばあらゆるニーズに対応できそうではある。
GPUはGRID K2が最大で8枚まで搭載できXeon E5ファミリーが2ソケット搭載される。

価格はフルカスタマイズで292万(サーバー本体)+50万(仮想サーバーライセンス)=342万がイニシャルでかかる。ランニングは仮想サーバーライセンスとDCの運用コストのみでよさそうだ。

ただエンタープライズレベルで使うには高い可用性求められるので2セット必要で、ライセンスはスタンバイモードでの運用することを考慮すれば多少は安くなりそうである。

フルカスタマイズにすると1ラックの電気容量では賄えないレベルの電力を消費する可能性が高いので電気容量には要注意である。

仮想化基板がインストールされることを想定しており仮想ディスクトップ向けを想定しているので大規模なクラウドゲーミングプラットフォームとの相性はそこまでよくないだろう。

グラフィックの性能は以下の表を参照されたし。





VCAの仮想化テクノロジー


仮想化上でGPU使うなんてありえないと思っていたがさすがNVIDIA、独自ドライバーでこの問題をクリアしている。

大きく分けて手法は2つあり、パススルー方式かソフトウェアエンコード方式。

パススルー方式はGPUのコアを仮想マシンに直接結びつけることができる。もちろんHypervisorがパススルーに対応する必要がありVmwareとXenが現状対応してそうだ。

パススルーはGPUに直接仕事をぶん投げるのでGPUへのオーバーヘッドは最小限に抑えれそう。
ただこれには若干問題があり、コアを直接割り当てるということは恐らくGPUのコア数が仮想マシンの数の最大数になるはず。
HypervisorはVCPUをサポートしているのでコア数を超えても仮想マシンを作成できるがGPUの制限で作成できないという問題が発生する。

次にソフトウェアエンコード方式でこれはゲストOS上にドライバーをインストールしてGPUをエミュレートしてに命令を流す方式。パススルーと比べてパフォーマンスは低下するがGPUコアを有効活用できそうだ。ただエミュレートしたGPUでは使えない命令セットがあるのでその場合採用は不可能になる。おそらくDirectXなどもろに影響を受けると思うので検証が必要である。

クラスタを組んでGPGPUとして使うのは可能だがコスパはよくなさそうである。

AWSでの運用


可能であれば私はこの選択を取りたいと思った。

  1. サーバーの運用
  2. 高い可用性
  3. 従量課金
この3点どれをとっても最もコスパがよさそうだと感じたからである。

現在のインスタンスタイプでGPUを積んでいるものはcg1.4xlargeしかない。
性能は以下になる。
vCPU:16
メモリ:22.5
ネットワーク:10 ギガビット

Windowsの場合AWSの画面を見る限りクライアントOSには対応してそうにはないのでWindowServerなどを採用する必要ありそうだ。

GPUはTesla M2050を2つ搭載しているようだ。ただWindowsServerなのでVCAで紹介したパススルーなどのテクノロジーを利用することはできない。つまり仮想ディスクトップなどの用途にはまったくもって向いていない。

HPCでの利用を想定しているのでAWSのツールを使えば簡単にClusterを構築できるのは大きな魅力でノードさえ追加していけば計算能力をスケールさせることが容易に可能。
画像処理やGPUを有効活用できるプログラムには大きな効果を発揮するがクラウドゲーミングでの利用はクラスタ構成をアプリ側にも考慮してもらう必要があるのでかなり導入の閾値は高そうだ。

そして大きな問題がある。なんと現時点では日本いリージョンがないので例え作りこんだとしてもレイテンシーの問題をクリアすることが極めて困難だ。

料金に関してはイニシャルコストが発生せずランニングだけでいいのがAWSの魅力。
今のレートだと1HPCインスタンス一日4千円程度だ。

クラウドゲーミングプラットフォームプロバイダ

グラウドゲーミングのプラットフォームを提供しているベンダーが4つ程度あるのを確認できた。
Agawi、Playcast、ubitus、G-clusterだ。

この4つともバックエンドにはNVIDIAのプラットフォームを採用している。

このプラットフォームとゲーム側との接続はブラックボックスだが恐らくゲーム処理と画像処理をストリームで相互通信するのだろう。

既存のゲームシステムをクラウドゲーミング化するのにはもってこいのプラットフォームで既存システムはほぼそのままでクライアント側のシステムをプラットフォーム側で動かすために改良を加えれば事は済みそうである。

クラウドゲーミングはTCP/UDP通信を多様しているはずなので既存のCDNプラットフォームを利用した地理的な分散やトラフィックのコントロールは恐らく現時点では実現できない。
そのためプラットフォームベンダーによっては国限定のサービスになるかもしれない。

第四の選択


恐らくここまで来ると「クラウドゲーミングプラットフォーム作るのんかなり困難かつコスパ悪くね?」と思うはず。
第四の選択はグラボを搭載したサーバー郡を構築することだ。
前述したNVIDIAのアプライアンスサーバーを自作する形式だが、私の知る限りクライアントOSなどに対応したIAサーバーはあまり無い。
SUPERMICROなどASUSなどのベンダーがグラボを搭載したラック型のサーバーを提供している。
H○やD○○○やI○○など慣れ親しんだサーバーではないので若干不安が残るのが正直な感想。


しかし近年CPU内蔵GPUであるAPUがクライアントPCに出てき始めた。
APUはGPUをより汎用化させた通常のプロセッサの役割も担えるようすることでGPGPUでは専用のソフトウェアが必要であったが不要になりそうだ。
APUはAMDの開発が進んでおりそろそろサーバー用のAPUとしてリリースしてもいいんじゃないかと思っている。どうなんでしょうかAMDさん。

このAPUが市場にでればこれまでの問題は大きくクリアされる。
GPUを積まなくても高速かつ美しい描画が可能になり専用のドライバーを使った仮想化との融合も考えなくていい。
大規模な分散処理は各企業ノウハウがあることが多いので、このノウハウをそのまま利用しクラウドゲーミングのプラットフォームを構築可能だ。

APUの市場は大きく拡大すると思う。APUさえあれば高性能なグラフィックカードを積んだPCは必要なくなりラップトップでもグラフィックカード並みの性能を引き出せることになる。
NVIDIAやIntelも競合として現れ価格やシリーズの競合が多く発生するだろう。

クラウドゲーミングのプラットフォームはAPUの登場で大きく前進すると思うので今すぐ構築するのはイバラの道を進みそうである。


2013年9月8日日曜日

CloudStack 4.0系 KVM でDELLを使う時は注意 #cloudstack

Failed to get public nic name

KVMのagent.logにこのエラーが出力されうまくホストが追加されなかった。
publicの部分は環境によって異なるのだがうまくNICを認識できていないようだった。

NICのVLANを見なおしたり、Bridgeを作りなおしたりしたのだが改善されず。


/etc/cloud/agent/agent.propertiesを見てもNICとBridgeのマッピングは問題なさそうだった。


ただこの問題が起きるのはなぜかDELLマシンだけ‥


NICの命名規則

NICの命名規則がFredora15とCent6.1辺りから変更があり、これまでNIC名はethだったのだが物理デバイス名を意識した命名規則になった。

オンボードNICならemXのような形式になる。

この命名規則を有効にするにはOS側だけでなくBIOSが対応している必要がある。

最近のサーバーはBIOSも対応しておりただ、有効になっているのはDELLだけ‥


このような命名規則になったのは色々理由があるのだがDELL自身のサイトがまとめているので参考にしてほしい。
http://ja.community.dell.com/techcenter/b/weblog/archive/2011/08/03/fedora-15.aspx


ただ全てのサーバーとOSが対応していない現状を伺うとこの設定は無効にしている方が懸命であ
る。

DELLマシンを使うとKickstartやライブマイグレーションが正常に行えない問題が起きることもある。

実はFailed to get public nic nameの問題に関係している。


biosdevnameを無効にする

biosdevnameを無効にすることで、従来のeth方式の命名規則に変更できる。

grub.confの起動パラメータにbiosdevname=0を追記し再起動すれば問題ない。


CloudStack 4.0系はbiosdevnameに対応していない

問題はこれだった。比較的安定している(と思っている)4.0.2系を使っていたのだがうまくNICを認識しない。

これはCloudStack4.0系 + KVMで発生する問題で4.0系を使っていたもVMなら恐らくこの問題は起きない。

./plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.javaを見ると、NICの判定がある。

ホストが追加される時はSSHを経由してagentからLibvertがキックされるのだがその際にVLANの設定をチェックしNICとBridgeのマッピングを行うのだが、NICの判定がethかbondのみになっているのが問題。
emやpciなどのNICは見つけられないのでBridgeとマッピングできずにFailed to get public nic nameが発生する。

この問題はCloudStack4.1以上で対策されている。

そもそも4.0系ってCent6.1対応外だったのかも‥


クラウドでは様々なベンダーのサーバーを使うと思うのでbiosdevnameは無効にしておきたいところ。



2013年8月29日木曜日

easy_install でopen('/dev/null', 'w')エラーが発生する


easy_install のBugが起因。

現在のところ回避方法はないためpipでのインストールで対応するしかなさそう。

https://bitbucket.org/tarek/distribute/issue/101

#easy_install pip

2013年8月27日火曜日

CloudStack 4.1.1 KVM の基本構築 #cloudstack

ここ一ヶ月ぐらいCloudStack(CS)を触ってみたのでメモしておきます。


環境
今回は私は仮想環境ではなく物理環境で構築しましたが仮想環境でもほとんど変わらないと思います。
  • CloudStack 4.1.1
  • KVM(CentOS 6.4)
  • Catalyst 2960(なくてもいい)
  • VLAN 10個ぐらい(今回はVLAN100~110)
  • ネットワークセグメント 4つ程度
  • NFS(KVM以外のサーバーが望ましいがコントローラーと同じ場所などに構築する)
  • SELinuxは絶対無効にする
  • とりあえずiptablesも無効にする(プロダクションでは設定した方がいいかも)

ネットワーク
CloudStackはネットワーク設計がめっちゃめっちゃ重要になります。
あとで変更するのにはかなり苦労するうえにBugで消せなかったりするのでプロダクションとして構築する場合は注意しましょう。
ethの場合はem1(eth0)、em2(eth1)と読み替えてください。

VLAN  NIC  bridge    Type
100  em2  cloudbr2  guest
101  em1  cloudbr0 public
102  em2  cloudbr3 manage
103  em2  cloudbr1 storage

guest:ゲストOSに割り当てられるIP
public:guestからNATに変換される先のIP(拡張ネットワーク)
manage:ホストOSとシステムVMに割り当てられコントローラーと通信する
storage:ホストOSとストレージとの通信に利用する

storageとmanageは同じセグメントでも可能。
プロダクションだと分けないとSPOFになる。

NICは2つあれば構築しやすいですが1つでも可能です。
仮想マシンでSSHしか使えない環境ですと設定を誤るとSSHが途切れるのでSSHのポートだけ別NICにするか別VLANにするなどCSの影響範囲外に置いてくと無難です。


105~110はコントローラーから拡張ネットワークでゾーンを構築する際にVLANの範囲を指定しますのでその際に105と110を指定してください。

NFS

CSにはプライマリーストレージとセカンダリーストレージの2つの概念がありそれぞれ別々の役割を持っているので必ず構築する必要がある。

VLAN 102のセグメントのIPを割り当て、VLAN 102のセグメントからアクセスできるようにする必要があります。


#yum install nfs-utils

# mkdir -p /export/primary
# mkdir -p /export/secondary

# vi /etc/exports
/export  *(rw,async,no_root_squash)

# exportfs -a

# vi /etc/sysconfig/nfs
Uncomment the following lines:
LOCKD_TCPPORT=32803
LOCKD_UDPPORT=32769
MOUNTD_PORT=892
RQUOTAD_PORT=875
STATD_PORT=662
STATD_OUTGOING_PORT=2020


# service rpcbind start
# service nfs start
# chkconfig nfs on
# chkconfig rpcbind on

最後にマウント可能か確認

# mkdir /mnt/primarymount
# mount -t nfs {NFS IP}:/export/primary /mnt/primarymount
# umount /mnt/primarymount

ここでやっているのはポートの固定化とパーミッションの設定です。
基本手動でNFSをマウントする必要はありません。


KVM

#vi /etc/yum.repos.d/cloudstack.repo
[cloudstack]
name=cloudstack
baseurl=http://cloudstack.apt-get.eu/rhel/4.1/
enabled=1
gpgcheck=0


#yum clean all
#yum install cloudstack-agent

FQDNがサーバーについていないとエラーになるのでFQDNをつけておく
#hostname -f

#vi /etc/libvirt/libvirtd.conf
listen_tls = 0
listen_tcp = 1
tcp_port = "16509"
auth_tcp = "none"
mdns_adv = 0

#vi /etc/sysconfig/libvirtd
LIBVIRTD_ARGS="--listen"

#service libvirtd restart

起動すれば問題ないです。

virbr0は使わないので削除してもあっても問題ないです。
削除する場合
#virsh net-destroy default
#virsh net-autostart default --disable


VLANの設定
私の環境ではスイッチのポートをTrunkにしているのでLinux側でTagginします。
サーバー側が複数NICでアクセスポートにしている場合は以下の設定は不要です。

VLANはifcfg-{nic}.{vlan-id}で指定しvlan=yesを追記すると有効になります。
aliasを利用する場合はifcfg-{nic}.{vlan-id}:{alias-num}で可能かと思います。

VLAN  NIC  bridge    Type
100  em2  cloudbr2  guest
101  em1  cloudbr0 public
102  em2  cloudbr3 manage
103  em2  cloudbr1 storage

この設定をします。

IPADDRやNETMASKの設定が必要な場合はbridge側に設定します。

#cd /etc/sysconfig/network-scripts
#vi cloudbr0
DEVICE=cloudbr0
TYPE=Bridge
ONBOOT=yes
BOOTPROTO=none
IPV6INIT=no
IPV6_AUTOCONF=no
DELAY=1

#vi cloudbr1
DEVICE=cloudbr1
TYPE=Bridge
ONBOOT=yes
BOOTPROTO=none
IPV6INIT=no
IPV6_AUTOCONF=no
DELAY=1

#vi cloudbr2
DEVICE=cloudbr2
TYPE=Bridge
ONBOOT=yes
BOOTPROTO=none
IPV6INIT=no
IPV6_AUTOCONF=no
DELAY=1

#vi cloudbr3
DEVICE=cloudbr3
TYPE=Bridge
ONBOOT=yes
BOOTPROTO=none
IPV6INIT=no
IPV6_AUTOCONF=no
DELAY=1

#vi ifcfg-em1
DEVICE="em1"
BOOTPROTO=none
NM_CONTROLLED="yes"
ONBOOT=yes
TYPE="Ethernet"
DEFROUTE=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME="Global Nat"
VLAN=yes
BRIDGE=cloudbr0

#vi ifcfg-em2
DEVICE="em2"
BOOTPROTO=none
NM_CONTROLLED="yes"
ONBOOT=yes
TYPE="Ethernet"
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME="System em2"

#vi ifcfg-em2.100
DEVICE="em2.100"
BOOTPROTO=none
NM_CONTROLLED="yes"
ONBOOT=yes
TYPE="Ethernet"
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME="Private"
VLAN=yes
BRIDGE=cloudbr2

#vi ifcfg-em2.102
DEVICE="em2.102"
BOOTPROTO=none
NM_CONTROLLED="yes"
ONBOOT=yes
DEFROUTE=yes
TYPE="Ethernet"
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME="management"
VLAN=yes
BRIDGE=cloudbr3

#vi ifcfg-em2.103
DEVICE="em2.103"
BOOTPROTO=none
NM_CONTROLLED="yes"
ONBOOT=yes
DEFROUTE=yes
TYPE="Ethernet"
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME="Storage"
VLAN=yes
BRIDGE=cloudbr1

VLAN 101はコントローラーの制御に入れば動的に作られるようなのでここでは作成しません。
bridgeとNICの結びつきと設定はハマりポイントなので注意して設定してください。

cloudbrという名前は変更しても問題ないです。
これが構築後に設定するKVMのラベル名となります。


コントローラー

コントローラーとはハイパーバイザーなどを管理しWebUIなどを提供するCloudStackそのものです。
パッケージ名だとserverやmanagerなどの名前がついています。私は便宜上コントローラーと呼んでおります。

KVMと同様にFQDNとyumのリポジトリを設定してください。

#yum install cloudstack-management
#yum install mysql-server

#vi /etc/my.cnf に追記
[mysqld]
innodb_rollback_on_timeout=1
innodb_lock_wait_timeout=600
max_connections=350
log-bin=mysql-bin
binlog-format = 'ROW'


#service mysqld start

MySQLでcloudユーザーを作成しrootユーザにパスワードを設定してください。


テーブルの作成
#cloudstack-setup-databases cloud:{cloud_user [email protected] --deploy-as=root:{root_pass}


CSを初期化したい場合はcloudstack-managementを停止した後にcloud、cloud_usage、cloudbridgeのデーターベースを削除し再度cloudstack-setup-databasesを実行すれば初期化できます。


コントローラー側でシステムVMをダウンロードします。
セカンダリーストレージにダウンロードするので予めマウントしておきます。
#/usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary -u http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2 -h kvm  -F


/usr/sbin/tomcat6: line 30: /usr/share/cloud/management/logs/catalina.out: Permission deniedが発生するのでパーミッションを変更します。

chmod 777 /usr/share/cloud/management/logs/catalina.out

ここまでくるとコントローラーが起動すると思います。

起動後、初期プロビジョニングが実行されるので少し待ってからアクセスしてください。

#service cloudstack-setup-management start
#netstat -nl
8080がListenしていれば問題ありません。

起動してない場合はログを見直しましょう。
/var/log/cloud/management/management-server.log

http://{ip}:8080/client/
ユーザ:admin
パスワード:password
ドメイン:指定なし

IPの部分ですがem1(eth0)側がアップリンクになっている場合は優先的にeth0のIPを優先するようです。eth1でアクセスしたい場合は一時的にeth1をダウンさせましょう。
#ifdown em1(etn0)

ログインできれば、ウィザードにしたがって構築可能です。
詳しい構築方法は後ほど公開します。



2013年8月26日月曜日

これからCloudStackを始める人へ #cloudstack

これからCloudStackを始める人へ

コミュニティに参加する
https://groups.google.com/forum/#!forum/cloudstack-ja

有益な情報が結構流れ来るので参加している方が吉。
また質問もここからできるので本当に困ったときは力になってくれる。

Twitter
https://twitter.com/cloudstackja
https://twitter.com/cloudstack_jpn
https://twitter.com/kimotuki
https://twitter.com/kkitase

こちらも有益な情報やイベント情報が流れてくるのでフォローしておく。

ドキュメント
http://cloudstack.apache.org/docs/en-US/index.html

CloudStackはドキュメントがかなり充実しているのでこれさえあればある程度構築可能。

ログのありか
コントローラー側
#/var/log/cloud/management/management-server.log
#/var/log/cloud/management/catalina.out

management-server.logは2013-08-25 00:02:56,327 DEBUG [hogehoge]と出力されるのでこのhogehogeの部分をgrepすると一連の流れがわかる。
このログはよく見るとエラーの内容がわかる。

catalina.outはJavaのExceptionが出力されるのでこれもエラーの原因解明につながる。

ホスト側
#/var/log/cloud/agent/agent.log
#/var/log/messages

基本ホスト側のエラーログよりもコントローラー側のエラーログの方が原因が分かることが多いのだが両方のログを必ず確認してほしい。

書籍

システムVM?pod?クラスター?プライマリーストレージ?と全体の概要を掴まないとなかなか理解できないのでハンドブックとしては大きすぎるが悩んだ時に見ると気付くことが多い。

使うバージョンを決める
4.2系か4.1系か4.0系かを決める。
4.2系は現時点ではRPMがないため自分でビルドする必要があると思う。
後、注意してほしいのがIssuesだ。
常にドキュメントで自分が使うバージョンにどのようなBugあって自身のクラウド環境に影響がないか必ず確認したいところ。
Issuesはリリースノートから確認できる。
4.1だとこちら。
http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.1.1/html/Release_Notes/version-4.1.html#issues-fixed-4.1.1

サーバー
物理マシン1台
仮想マシン1台

プロダクションで使うなら
L2スイッチ

VALNを自由に作れるとよりプロダクション環境に近づけるのでいいかも。

Java
書けなくてもいいですがコードを読めるとハマった時気付くことが多い。


最後に

OpenStackもCloudStackも同じことが言えるのだが、それなりに安定させた状態でサービスを開始するにはそれなりに苦労すると思われる。

と初めに凹むような事を書いたが、クラウドと聞くと大きな幻想を抱いている人が多いので予め言っておく。

クラウド基盤の下で動いているものは普通のVMwareだったりKVMだったりするのでハイパーバイザーの機能を超えた何かを特別に持っているわけではない。

クラウド基盤によってエージェントを入れることで、クラウド基盤には重要なライブマイグレーションなどを実現していることがある。

まだまだプライベートクラウドは過渡期な物なのでBugが多く、とても不安定な部分も多くあるため大きな心の余裕を持って挑んでほしい。

ただオープンソースでコミュニティも活発なので自身でモノづくりをしている楽しみを味わえるのがエンジニアだととても楽しいと思う。

サービスで導入することを真剣に考えている場合はシトリックスやRedHat(KVM)+シトリックス、VMware vCenter Serverを視野に入れて比較検討すること推奨する。

VMwareの回し者ではないがVMwareは本当によく出来ているアプリケーションだとプライベートクラウドを構築して素直にそう思った。そしてAWSは凄い。あそこまで安定化させるためには相当なノウハウが必要だ。

ここ最近OpenStackとCloudStackをサポートする企業やこれらのクラウド基盤を下にカスタマイズした自社製クラウド基盤を出しているメーカも多い。

後者の場合サーバーベンダーなどが注力してサーバーとオールインワンで導入しているケースをよく見る。

自分自身の環境にマッチしたクラウド基盤を選定してほしい。


一緒に頑張りましょう!

2013年8月18日日曜日

wgetのFTPが便利

誰もが1度は使ったことであろうwgetコマンド。

このコマンドはWebページ上のファイルを取得するだけでなくWebページを再帰的に辿りまるごと取得もできるすぐれもの。


webページのリンクを辿り再帰的に取得する
 wget -r http://www.example.com/index.html

webページのリンクをが外部リンクでも取得する
 wget -r -H http://www.example.com/index.html

BASIC認証が設定されているファイルを取得する
 wget --http-user=user_name --http-password=pass http://www.example.com/index.html

サイトをまるごとコピーする
 wget -m http://www.example.com/index.html

まるごと取得する階層を指定する
 wget -l 1 http://www.example.com/index.html

BASIC認証が設定されているファイルを取得する
 wget --http-user=user_name --http-password=pass http://www.example.com/index.html

絶対パス(外部リンク)を相対パスに変換する
 wget -k http://www.example.com/index.html

リンク中の画像も取得する
 wget -p http://www.example.com/index.html


ここまでは常用の範囲かと思いますが、実は-rと-mはFTPでも使えちゃうという便利コマンド。
wgetってHTTP/HTTPS意外でも使えるのをmanで初めて知った。

ftpコマンドは再帰的にディレクトリを辿ってダウンロードできないのでまとめてダウンロードする際は不便です。

wgetでFTPをする
wget -m --passive-ftp ftp://user:[email protected]/{dir}

cオプションでレジューム機能も使えます
wget -cm --passive-ftp ftp://user:[email protected]/{dir}




2013年4月4日木曜日

Postfixのsaid: 553 sorry, your envelope sender domain must existの対処

急にメールが送れなくなったと思いメールログを見てみると。

host mail.hoge.jp[111.222.222.111] said: 553 sorry, your envelope sender domain must exist (#5.7.1) (in reply to MAIL FROM command))


というログが大量にでていました。

なんとなくFromがおかしいのかなとあたりをつけ、ログからFromを見てみると

from=, size=820, nrcpt=1 (queue active)

という具合になっており、サーバのFQDNがFROMとして使われていました。

このFROMが正引きできるFQDNでないとエラーになることがあります。
おそらくPostfixをちゃんと設定していれば問題ないと思います。

/etc/postfix/main.cfの以下の部分を正しく書き換えます。

#myorigin = $myhostname
myorigin = kubox.info
...
#myorigin = $myhostname
myorigin = $mydomain


Postfixを再起動します。

最近はSPAM判定が厳しくなっているのでmyoriginと実際に配信しようとしているサーバのIPの逆引きが一致しないと送信できない場合があるので、SPFレコードなども設定しておきましょう。

プライベートのメールを見てみるとメール送信の判定を厳しくするよ!ってきました‥

日本語の情報が少なかったのメモ程度に記録しておきます。

2013年3月5日火曜日

kuboxをSPDYに対応させました(nginx)

SPDY(スピーディー)は、Googleが提唱し、現在標準化作業が進められている通信プロトコルの一つ。

https://blog.kubox.info(警告がでます)

詳細はSPDYメモがよく纏められています。

NginxをSPDYに対応させる


NginxはSPDYに1.3以上でないと対応しおらず、現状1.3はDev向けなのでサービスでの利用は推奨されていません。
なのでこのサイトのSSLもいつおかしくなるかわかりません。。。
自己証明でも可能です。

Nginx1.3のDevはインストールページからダウンロード可能です。
Nginx ダウンロード

SPDYはSSLでの利用前提で開発されている(らしい)のでOpenSSL1以上が必須になっています。
http://www.openssl.org/source/

ヘッダーファイルが欲しいだけなので既存のOpenSSL0.9は消さなくても大丈夫です。
ダウンロードしたOpenSSLを適当なところで展開だけ済ませておいてください。今回は/usr/local/src配下に展開されたとします。

Nginx1.3にSPDYのパッチを当てます
nginx1.3# wget http://nginx.org/patches/spdy/patch.spdy.txt
nginx1.3# patch -p1 < patch.spdy.txt


Nginx1.3のconfigureオプションにsslとSPDYを追加します。
このサーバにはport80でこのBlogがNginxで動いているのでprefixでディレクトリを分けてます。
これでstableとdevを共存させることができます。

./configure \
--prefix=/usr/local/nginx-spdypatch-1.3.13 \
--with-openssl=/usr/local/src/openssl-1.0.1e \
--with-http_ssl_module \
--with-http_spdy_module \


nginx.confにSPDYの設定とSSLの設定を追記します。

server {
                listen 443 ssl spdy default_server;
                ssl_certificate /usr/local/nginx-spdypatch-1.3.13/crt/server.crt;
                ssl_certificate_key   /usr/local/nginx-spdypatch-1.3.13/crt/server.key;
                ssl on;
                ssl_session_timeout 5m;
                ssl_protocols SSLv2 SSLv3 TLSv1;
                ssl_ciphers HIGH:!aNULL:!MD5;
                ssl_prefer_server_ciphers on;

                spdy_max_concurrent_streams 100;
                spdy_streams_index_size     32;
                spdy_recv_timeout           30s;
                spdy_keepalive_timeout      3m;
                spdy_headers_comp           9;
....

}


別途initスクリプトを置くのはめんどくさいので手動で起動します。
/usr/local/nginx-spdypatch-1.3.13/sbin/nginx -c /usr/local/nginx-spdypatch-1.3.13/conf/nginx.conf


ブラウザがChromeであればエクステンションで確認できます。
SPDY indicator

URLにchrome://net-internals/#spdyを入力することでも確認できます。



SPDYの動作が確認できない場合はログには特にでないので、OpenSSLのバージョンnginxのconfigureオプションなどを確認してみてください。

2013年3月1日金曜日

Chef Practice :: 環境が異なっても同じレシピを使うパターン1 #opschef

dev、staging、productionとそれぞれの環境が異なる事が殆どです。

これらの環境ごとにCookbookやrecipeを分けるのも1つの方法ですが冗長になる運用コストが高いので可能な限り1つのrecipeにまとめれたほうがよいです。

Chef-serverを使うことでこの環境の差は比較的用意に乗り越えることができます。

environment


environmentでそれぞれの環境分作りノードを予め割り当てておきます。

recipe内からはnode.chef_environmentでenvironmentを取得できます。

if node.chef_environment =~ /staging|production/

else

end


environmentはchef-client実行時に"chef-client -E Production"と実行している場合は注意してください。
この場合Attributesのchef_environmentとして登録されます。

if node[:chef_environment] =~ /staging|production/

else

end


environmentとtemplates


templates利用する際はrecipe内でnode.chef_environmentを書くよりも環境ごとにtemplatesを準備します。


template "/etc/passwd" do
source "passwd." + node.chef_environment + "conf.erb"
end


attributesとenvironmentとtemplates



templatesを環境ごとにつくらずattributesにまとめる方法です。
ex)attributes/default.rb

default["passwd"]["open"] = [
"root:x:0:0:root:/root:/bin/bash",
"bin:x:1:1:bin:/bin:/sbin/nologin",
"daemon:x:2:2:daemon:/sbin:/sbin/nologin",
...


ex)recipes/default.rb


template "/etc/passwd" do
mode 00644
source "/etc/passwd.erb"
if node[:chef_environment] =~ /staging|production/

else

end
end

2013年2月13日水曜日

Chefのインストールがすごく簡単になってたので3行で書く

・RPMで一発インストール
・Cent/Debian/OS X/Ubuntu/Windowsまでパッケージ化されてる
・もちろんRubyも入るけど/opt配下に全てインストールされて既存のRubyには影響なし

Chef-clientのインストールはRuby入れてGemからChef入れて、ServerはSoloから入れるのがセオリーだったのですがRPMで一発で入るようになってて素晴らしい。
http://www.opscode.com/chef/install/


Chef11からRPMがあるのかーって思ってたけど全部あった。

2013年2月6日水曜日

ssh_exchange_identification: Connection closed by remote host

このエラーが出た時はひとまずこのサイトを見てほしい。
http://wsjp.blogspot.jp/2012/08/sshexchangeidentification-connection.html

きっとうちのサイトに来たということは、上記のサイトの方法で解決しなかったからだと思う。

192.168.10.11/32を許可するためのhosts.allowをこんな感じで書いてた。

sshd: 192.168.10.11/255.255.255.255


しかしssh_exchange_identification: Connection closed by remote hostがでる。

なぜ??

255.255.255.255はお作法的にまずいらしい。

sshd: 192.168.10.11


にすると接続でけた。

2013年2月5日火曜日

Chef11リリースのメモ

Chef11がついにでましたね。
そろそろ寝ようと思ってたらGmailからのメールで起こされました。
明日のためにメモしておきます。

新機能


・インストールがより簡単に
オムニバスパッケージとしてRuby1.9も含めたRPMが準備されました。
install.shも用意されより簡単にChefServerとChefSoloを構築できるようになったみたいです。
ChefSoloで入れて標準インストールRubyとコンフリクトを起こす事故などが回避できそう。
後、RPMとSHということでキックスタート時により簡単に構築できそうです。

・APIサーバがErlangでフルスクラッチされた(まじかよ…)
APIサーバがErchefという名になるみたいです。Opscoodが呼んでるだけかも。
Chefホスティングの経験を活かしてより速く、より軽量に作りなおした。
MerbからRails3に移行した。

・フレームワークを作った
これは複数のプラットフォームで依存関係を解決するのを簡単にするため。
Omnibus framework
これらのライブラリーはすべてオムニバスパッケージに含まれている。
/optにあるから探してね。
そして何よりも/opt配下に集約されるようにしたので
もし興味があれば是非Gitからダウンロードしてほしい。
ちなみにRPMの中身はrpm -qlp ./hoge.rpmで見れます。

・Chef Clientの大幅な改善
Chefは単純にレシピを上から実行されるのでnode.my_attr("foo")のように書いておくと次に実行されるレシピやRoleが正常に動作しない問題があったが、Roleとenvironmentsを元により動的かつインテリジェンスに動作するようになった。

・Knifeコマンドの強化
knife diff
ChefサーバとChefリポジトリの差分表示
knife download
knife upload
knife list
knife show
knife delete
knife raw
http://docs.opscode.com/knife.html

diffが一番便利そう。

ダウンロードはここから(リリース30分で落ちちゃいました…)
http://www.opscode.com/chef/install/

機能の大幅な追加というよりは、現在のニーズに合わせたリファクタリングと高速化が主な変更点みたいです。
そしてより導入しやすく、より一貫性を保つことを強調したメジャーバージョンアップですね。

・PrivateChef(有料)
商用版Chefで20ノードまでが$120、50ノードまでが$300、100ノードまでが$600です。
http://www.opscode.com/private-chef/