ボリュームをファイルシステムとして使用するまでの流れ
今までなんとなく"触れちゃいけないモノ"なイメージであまり近づかなかったパーティション周りの概念についてそれなりに理解できたので、あとで見たときに思い出せるように、その概念をつらつら書こうかなぁ・・・と思ったけどやめた。
頭の中にイメージはできてるんだけど上手く言葉に表現できなかったから。。
代わりに実際にパーティション作成からマウントまでの流れを描いてみる。
例として「/dev/sda」という物理ボリュームがあり、そのボリュームは既にsda1、sda2、とパーティションが分かれているがまだ空き容量がある。その空き容量をファイルシステムとして使用したいとする。
パーティションを作る
パーティションを作るにはfdiskコマンドを使用する。
fdisk /dev/sda
すると対話モードになるので、やりたいことをリクエストする。
細かい説明は面倒なのでしないけど、
- nで作成。パーティション番号（1、2は既にあるのでここでは3を指定）と使用ブロックを決める。
- tで領域のシステムID（タイプ）を変更（8eのLinuxLVMが後からのサイズ変更も容易なのでいいかなと思う。LVMについても別途詳しく書く。）
- pで確認してwで保存。
これで「/dev/sda3」が作られる。
rebootしろと言われたら素直にrebootする。
reboot
ファイルシステムを作る
作ったパーティションをファイルシステムとして使用するには適当なファイルシステムタイプへフォーマットする必要がある。
ファイルシステムにはext2,ext3,ext4など、色々な種類がある。
・ファイルシステムタイプ一覧。
http://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0#.E6.AF.94.E8.BC.83
色々種類はあるが、Linuxならext4辺り使っとけばいいんじゃねーの程度の理解。
ファイルシステムを作成するには「mkfs.ファイルシステム名」コマンドで。
sda3をext4にしたい場合は
mkfs.ext4 /dev/sda3
など。
インスタンスストアAMIを作成するとauthorized_keysやpemが消える件
なんかAmazonのポリシーでAMI作るときは徹底的に鍵を消すらしい。
今までAMIの中に公開鍵仕込んでパス無し認証を実現させていたので困った。
色々実験してみたらaaaとかbbbって名前なら消されないようだったので、id_rsa.pubをbbbって名前にリネームしてOS起動時に呼ばれるファイル（/etc/rc.local）に
cat bbb >> authorized_keys
みたいなコードを入れてなんとか回避した。
けど、その後ec2-bundle-volの「-i」オプションで回避できることを知った。
ec2-bundle-vol -d /mnt --privatekey pk-XXX.pem --cert cert-XXX.pem --user XXXX-XXXX-XXXX -i "/消したくないファイルのパス.pem","/unko/.ssh/authorized_keys"
みたいな感じで消したくないファイルをカンマ区切りで繋げるだけ。
EC2インスタンスにsshできなかった件
RightScale製のインスタンスを鍵指定無し（AMIの中に公開鍵仕込んでたので必要なかった）で立ち上げてsshしたんだけど
ssh: connect to host 1.2.3.4 port 22: Connection refused
こんな事を言われて入れなかった。
瞬間言われるので多分ネットワークは生きてる。おそらくポート22をListenしているプロセスがいない…？
で、AWS管理画面からシステムログを確認してみると
Fetching list of trusted keys from metadata server...
このログを最後に止まってる。追ってみたらこのログはどうやらgetsshkey（ライトスケールが用意してくれた、インスタンス立ち上げの時に指定した鍵を自動で取得するスクリプト）が出しているようだった。
おそらくこのスクリプトで止まっていてsshd起動までの処理に辿りつけて無い。
という事で、どうもこのスクリプトがいけてなさそう（鍵指定が無いと止まってしまう？）で、このスクリプトを修正するのもなんだかなぁと思ったので、今までやっていた「/etc/rc.local」にスクリプト書いて鍵を取得する方法でやる事にしてみた。
getsshkeyをサービスから外す
chkconfig --del getsshkey
/etc/rc.localを下記記事を参考に編集。
http://blog.suz-lab.com/2011/05/suz-lab-centos-ami-562-32bit-ap.html
PUB_KEY_URI=http://169.254.169.254/1.0/meta-data/public-keys/0/openssh-key PUB_KEY_FROM_HTTP=/tmp/openssh_id.pub ROOT_AUTHORIZED_KEYS=/root/.ssh/authorized_keys curl --retry 3 --retry-delay 0 --silent --fail -o $PUB_KEY_FROM_HTTP $PUB_KEY_URI if [ $? -eq 0 -a -e $PUB_KEY_FROM_HTTP ] ; then if ! grep -q -f $PUB_KEY_FROM_HTTP $ROOT_AUTHORIZED_KEYS then cat $PUB_KEY_FROM_HTTP >> $ROOT_AUTHORIZED_KEYS echo "New key added to authrozied keys file from parameters" | logger -t "aws" dd if=/dev/urandom count=50 | md5sum | passwd --stdin root echo "The root password randomized" | logger -t "aws" fi chmod 600 $ROOT_AUTHORIZED_KEYS rm -f $PUB_KEY_FROM_HTTP fi
これで行けるようになった。
memcacheの速度比較
python_memcachedよりもpylibmc（libmemcachedのpythonバインディング）のほうが速いらしいので試してみた。
環境
CentOS6.0
memcached-1.4.10
libmemcached-1.0.2-1.el6
python_memcached-1.47
pylibmc-0.2.1
結果
get,set,deleteと、それぞれのmultiについて10000回処理するのにどのくらい掛かるか測ってみた。
試行回数：10000 ------------------------------------------------------ - memcache ------------------------------------------------------ simple set : 3.656920 multi set : 0.303164 simple get : 3.608972 multi get : 0.327255 simple del : 3.397653 multi del : 0.247681 ------------------------------------------------------ - pylibmc ------------------------------------------------------ simple set : 3.035285 multi set : 2.977491 simple get : 3.040355 multi get : 0.036777 simple del : 3.049420 multi del : 2.944354
set_multi、delete_multiは圧倒的に遅いけど他はpylibmcのほうが速い。
特にget_multiに関しては10倍近く速いという結果になった。
使っているget、set、deleteの比率を見てどっち使うか決めるって感じかなぁ。
検証に使用したソースは↓
import datetime
import memcache
import pylibmc
TEST_NUM = 10000
SERVERS = ['0.0.0.0:11211','0.0.0.0:11211']
def getDiff(start):
delta = datetime.datetime.now() - start
return '%6f' % (delta.seconds + delta.microseconds / 1000000.0)
def do_test(client):
memcache_key_base = 'testaaaaa:aae:aa:%s'
# set.
# -simple.
start = datetime.datetime.now()
for i in xrange(TEST_NUM):
client.set(memcache_key_base % i, i)
print 'simple set : %s' % getDiff(start)
# multi.
start = datetime.datetime.now()
params = {}
for i in xrange(TEST_NUM):
params[memcache_key_base % i] = i
client.set_multi(params)
print 'multi set : %s' % getDiff(start)
# get.
# -simple.
start = datetime.datetime.now()
for i in xrange(TEST_NUM):
client.get(memcache_key_base % i)
print 'simple get : %s' % getDiff(start)
# multi.
start = datetime.datetime.now()
client.get_multi([memcache_key_base % i for i in xrange(TEST_NUM)])
print 'multi get : %s' % getDiff(start)
# delete.
# -simple.
start = datetime.datetime.now()
for i in xrange(TEST_NUM):
client.delete(memcache_key_base % i)
print 'simple del : %s' % getDiff(start)
# multi.
start = datetime.datetime.now()
client.delete_multi([memcache_key_base % i for i in xrange(TEST_NUM)])
print 'multi del : %s' % getDiff(start)
print u'試行回数：%s' % TEST_NUM
print u'------------------------------------------------------'
print u'- memcache test'
print u'------------------------------------------------------'
do_test(memcache.Client(SERVERS))
print u'------------------------------------------------------'
print u'- pylibmc test'
print u'------------------------------------------------------'
do_test(pylibmc.Client(SERVERS))
あとこれは余談だけどlibmemcachedをwindowsPCで使うのがかなり面倒だった。
さらにpylibmcを使うようにして負荷を掛けてみた（同時10で100request）ら500が返ってくるようになって、解決法が分からなかった。エラーログにはkeyのインクリメントに失敗しているような事が書かれてた。
なんだろう。
CentOS6.0でメモリ32GBまでしか認識してくれない件
EC2でx2.4xlargeタイプのインスタンスを立ち上げたんだけど、CentOS6.0がメモリ32BGまでしか認識してくれない、、
メモリ68GBつんでるハズなんだけどfreeとかしても
$ free
total used free shared buffers cached
Mem: 32677364 677180 32000184 0 9996 31076
-/+ buffers/cache: 636108 32041256
Swap: 3020212 0 3020212
こんな感じ。
色々調べてたらこんなつぶやき発見
CentOS6のどの時点化までのkernelではXenで32GBしかメモリ認識しないワナ…bit.ly/AcReytEC2 で 68GB メモリな m2.4xlarge 上げようとして発覚…version 上げも rebuild もメンドクサイだがなぁ…
— nakaharaさん (@ottan) 1月 15, 2012フォーラムのやりとりを見てみるとどうやらCONFIG_XEN_MAX_DOMAIN_MEMORY=32 でカーネルをビルドしているから32GBまでしか読んでくれないらしい。
確認してみる
$ less /boot/config-2.6.32-71.29.1.el6.x86_64 |grep CONFIG_XEN_MAX_DOMAIN_MEMORY CONFIG_XEN_MAX_DOMAIN_MEMORY=32
確かに32になってる。。
6.1以降であれば直っているらしいので、現時点で最新の6.2にアップデートした。
で、CentOS6.2のCONFIG_XEN_MAX_DOMAIN_MEMORYを確認。
$ less /boot/config-2.6.32-220.4.2.el6.x86_64 |grep CONFIG_XEN_MAX_DOMAIN_MEMORY CONFIG_XEN_MAX_DOMAIN_MEMORY=128
うん。128になってる。
これで68GB認識してくれるはず！と思ってfree見たけど変わらず、、
なんでだろーと思ってuname -r見てみたらカーネルのバージョンが変わってないようだった。
$ uname -r 2.6.32-71.29.1.el6.x86_64 ※CentOS6.2のカーネル番号は2.6.32-220.4.2.el6.x86_64
どうやら新カーネルで起動するように起動設定も変えないといけないらしい。
ということで「/boot/grub/menu.lst」を修正。
注意しないといけないのが6.2のカーネルにすると今までの「/dev/xvda」ボリュームが「/dev/xvde」になるということ。
この修正をしないで再起動したらカーネルパニック起こして起動しなかった。
システムログを確認してたら「xvdaなんてない。xvdeならあるけど。」みたいなログがあった。
なぜそうなるかは知らない。なんだろう・・・。
$ vi /boot/grub/menu.lst title CentOS Linux release 6.2 (Final) x86_64, with 2.6.32-220.4.2.el6.x86_64 root (hd0,0) kernel /boot/vmlinuz-2.6.32-220.4.2.el6.x86_64 root=/dev/xvde2 ro console=hvc0 crashkernel=auto SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=de-latin1-nodeadkeys initrd /boot/initramfs-2.6.32-220.4.2.el6.x86_64.img ※既存のCentOS6.0の起動設定はコメントアウトしておく。
※ちなみにライトスケールCentOS6.0のインスタンスストア起動タイプで試したときはhd0,0 -> hd0 へ修正した。こっちはパーティション割られてなかったみたい
あとマウント設定も修正しないといけない。
「/etc/fstab」のxvdaとなっている箇所をxvdeへと修正する。
$ vi /etc/fstab 〜省略
で、今度こそ再起動して確認。
$ free
total used free shared buffers cached
Mem: 70201052 863288 69337764 0 10160 31324
-/+ buffers/cache: 821804 69379248
Swap: 3020212 0 3020212
無事認識した。
まとめ
・CentOS6.0ではCONFIG_XEN_MAX_DOMAIN_MEMORYが32でビルドされているので、メモリ32GBまでしか認識しない。
・CentOS6.2では修正されているのでyum updateする。
・CentOS6.2のカーネルで起動するように設定。
・再起動してメモリ32GB以上認識する事を確認。
以上。
CentOSのアップデート
6.0から6.2へアップデートしたので方法をメモっておく。
アップデート
yum clean all yum update
で、終わったら再起動もする。
アップデート後のバージョン確認
$ cat /etc/redhat-release CentOS release 6.2 (Final)
以上。
※あとで分かったことだけど、このままではカーネルまでは新しくならなかった（yumの設定によると思いますが）
カーネル変更についてはこっちのCentOS6.0でメモリ32GBまでしか認識してくれない件の記事で触れてます。
無料版のはてブロでGoogleAdSense広告を非表示に
