検索
連載

わが社はいかにしてHadoopクラスター環境を構築したかとなりのアドテク(2)(3/5 ページ)

モバイル広告という、難度の高いサービスを展開する会社が、データ活用プラットフォームをRDBMSからHadoopに置き替えるまでの実録とハウツーを紹介します。

PC用表示 関連情報
Share
Tweet
LINE
Hatena

CMを使ったHadoopクラスター構築

 CMを使ってHadoopクラスターを構築するため、まずはHadoopサーバー側で事前準備を行います。この事前準備が終わった後にCMからの操作でHadoopクラスターやHadoopエコシステムの構築が可能になります。

 事前準備作業の内容は環境によっては不要なものもあります。パラメータなどは環境に合わせたものに適宜読み替えてください。

 「Parcel」というCM独自のパッケージ管理システムを利用するため、CMサーバーから見てクライアントになるサーバー(マスター/スレーブ問わず)に対してrootでのノンパスログインが必要になります。

 ノンパスログイン設定はインターネット上にたくさん情報があるのでここでは割愛しますが、まずはCMサーバーから全サーバーに、rootノンパスでログインできるよう設定します。

 スレーブサーバーで、2TB以上のディスクを利用する場合、通常のfdiskコマンドではパーティションを作成できません。そこで、partedコマンドを利用します。必要であればコマンドをインストールしておきましょう。

# yum install parted -y

sysctl.confの設定

 マスターサーバー、スレーブサーバー共にカーネルパラメータ(/etc/sysctl.conf)をチューニングします。以下は変更後の内容です。

vm.swappiness = 0
vm.overcommit_memory = 2
kernel.panic = 1
kernel.panic_on_oops = 1
kernel.softllockup_panic = 1
kernel.hung_task_panic = 1
kernel.sysrq = 1
kernel.sem = 250 32000 96 128
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.conf.all.log_martians = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_mem = 1048576 1048576 1048576
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_keepalive_time = 180
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.tcp_keepalive_intvl = 6
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
net.core.wmem_max = 16777216
net.core.rmem_max = 16777216
net.core.wmem_default = 1048576
net.core.rmem_default = 1048576
net.core.optmem_max = 20480
net.core.somaxconn = 1024
net.core.netdev_max_backlog = 4096
net.ipv4.conf.all.log_martians = 1

スレーブ側リソースリミット制限をチューニングする

 スレーブ側でリソースリミット制限(/etc/security/limits.conf)を設定します。

ファイルディスクリプター、プロセス数制限を緩める

 ファイルディスクリプタとプロセス数のデフォルト値1024では小さく、Hadoopではすぐに制限値にー達してしまうので制限を緩和する設定を行います。変更すべき設定は次の部分です。

* soft nproc unlimited
* hard nproc unlimited
* soft nofile 60000
* hard nofile 60000

CentOS 6.4の場合は注意 CentOS 6.4の場合、/etc/security/limits.d/90-nproc.confが起動時に読み込まれて、limits.confを変更しても反映されないという罠があります。



Transparent Hugepage Compactionをオフに

 「Transparent Hugepage Compaction」が有効の場合、Hadoopジョブのワークロード上、systemのCPU使用率が高騰する場合があります。デフォルト有効ですが、以下のコマンドで状態を確認し、有効になっている場合は停止します。

 「Transparent Hugepage Compaction」プロセス確認します。

# ps -ef | grep khugepaged
root    	30 	2  0 Oct08 ?    	00:00:05 [khugepaged]

 「Transparent Hugepage Compaction」自動起動を確認します。以下のように[always]となっている場合は自動起動有効になっています。

# cat /sys/kernel/mm/transparent_hugepage/enabled
[always] never

 「Transparent Hugepage Compaction」の自動起動を無効化します。以下のように[never]と設定します。

# cd /sys/kernel/mm/transparent_hugepage/
# echo never > enabled
# cat enabled
always [never]

 「Transparent Hugepage Compaction」の停止していることを確認します。

# ps uax |grep khugepaged |grep -v  grep

スレーブサーバーでのディレクトリ作成とディスクフォーマットとマウント

 前述の通り、ターゲットが2TB以上のサイズの場合はfdiskコマンドではなくpartedコマンドでディスクをフォーマットします。

 以下はディスク1本の操作になりますが、必要なディスクの本数分実施します。

 ディレクトリを適宜作成します。

# mkdir /data01

 パーティションとファイルシステムを作成します。

# parted /dev/sdb
# mklabel gpt
# mkpart primary ext4 512 1999.0G
# quit
# partprobe /dev/sdb
# mkfs -t ext4 /dev/sdb1

 パーティション状態を確認します。

# parted /dev/sdb1
GNU Parted 2.1
/dev/sdb1 を使用
GNU Parted へようこそ! コマンド一覧を見るには 'help' と入力してください。
(parted) print
モデル: 不明 (unknown)
ディスク /dev/sdb1: 1998GB
セクタサイズ (論理/物理): 512B/4096B
パーティションテーブル: loop
番号  開始   終了	サイズ  ファイルシステム  フラグ
 1	0.00B  1998GB  1998GB  ext4

 再起動時にファイルシステムチェックで長時間OSが起動しない状況を避けるため、自動ファイルシステムチェックを無効にします。

# tune2fs -c 0 -i 0 /dev/sdb1

 自動ファイルシステムチェック無効を確認します。「-1」なら無効になっています。

#tune2fs -l /dev/sdb1 | grep Maximum
Maximum mount count:  	-1

 自動マウントされるよう、次のようにfstabに追記しておきます。

/dev/sdb1           	/data01               	ext4	defaults,noatime    	0 2

 作成したパーティションをマウントします。

# mount -a

 マウント状況を確認します。

# df -h
/dev/sdb1         	1.8T     1G  1.8T   1% /data01

 これで事前準備は完了です。あとはCMからの操作ですが、前述した通り事前準備の内容は環境や方針に依存します。状況に合わせて実施してください。

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る