仮想IPアドレスの設定
Rac環境を構築するにあたり、仮想IPアドレスを設定する必要があるので、調べたことをメモ。
仮想IPアドレスとは
まず、仮想IPアドレスについて引用。
仮想IPアドレスとは、複数のコンピュータやNIC(ネットワークインターフェース)で共有されるIPアドレスのこと。1つのアドレスを複数のサーバなどで共有する手法で、一部の機器に障害が生じてアクセス不能になった場合でも、同じアドレスを引き継いでサービスを続行することができる。また、ロードバランサなどと共に使用することで、外部からのアクセスを複数のサーバに均等に割り振って負荷分散を計ることができる。
要は、1つのIPアドレスを共有することで、拡張性や可用性を高めるために使用されるらしい。
仮想IPアドレスの設定
1枚のNICに複数のIPアドレスを割り当てるためには、VIP用のデバイスファイル(eth0:1、eth0:2など)を作成するのが、一般的だったらしいが、最近は違う方法をとるらしい(というかCentOS6.4以降では使えなくなった?)。
※ デバイスファイルを作成する方法は下記を参照。
新しい方法では、デバイスファイル中に「IPADDR2」、「NETMASK2」のように末尾に数字を付加し、設定を記述することでIPエイリアスとして適用できるらしい。
具体的には下記のような感じ。
IPADDR="192.168.17.128"
NETMASK="255.255.255.0"
IPADDR2="192.168.17.129"
NETMASK2="255.255.255.0"
なお、設定したIPアドレスは『ifconfig』では確認できないが、『ip addr』なら確認できる。
ifconfig
eth0 Link encap:Ethernet HWaddr 00:0C:29:97:EA:2A
inet addr:192.168.17.128 Bcast:192.168.17.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe97:ea2a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3449 errors:0 dropped:0 overruns:0 frame:0
TX packets:2803 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:530973 (518.5 KiB) TX bytes:494480 (482.8 KiB)
eth1 Link encap:Ethernet HWaddr 00:0C:29:97:EA:34
inet addr:192.168.157.201 Bcast:192.168.157.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe97:ea34/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2157 errors:0 dropped:0 overruns:0 frame:0
TX packets:1282 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:241639 (235.9 KiB) TX bytes:331647 (323.8 KiB)
Interrupt:16 Base address:0x2024
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:7723 errors:0 dropped:0 overruns:0 frame:0
TX packets:7723 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1146468 (1.0 MiB) TX bytes:1146468 (1.0 MiB)
ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
link/ether 00:0c:29:97:ea:34 brd ff:ff:ff:ff:ff:ff
inet 192.168.157.201/24 brd 192.168.157.255 scope global eth1
inet6 fe80::20c:29ff:fe97:ea34/64 scope link
valid_lft forever preferred_lft forever
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:0c:29:97:ea:2a brd ff:ff:ff:ff:ff:ff
inet 192.168.17.128/24 brd 192.168.17.255 scope global eth0
inet 192.168.17.129/24 brd 192.168.17.255 scope global secondary eth0
inet6 fe80::20c:29ff:fe97:ea2a/64 scope link
valid_lft forever preferred_lft forever
タイムゾーンの設定
タイムゾーンの設定
NTPサーバの設定の際に時刻同期を行ったつもりだが、どうも正しい時刻を表示してくれない。そこで、dateコマンドの実行結果を確認してみると、タイムゾーンの設定が必要そうなことが分かった。
date
Sun Nov 15 05:59:40 PST 2015
上記dateコマンドの結果ではタイムゾーンがPST、つまり太平洋時間(日本時間 -17)を示していることになる。以下のようにアメリカ西海岸の標準時間であるらしい。
太平洋標準時(たいへいようひょうじゅんじ、Pacific Standard Time: 略称PST)は、西海岸標準時(にしかいがんひょうじゅんじ)ともいい、協定世界時(UTC)を8時間遅らせた、主にアメリカ西海岸の地域の標準時である。「-0800(PST)」のように表示する。
なお、夏時間では協定世界時より7時間遅れ、太平洋夏時間(Pacific Daylight Time: 略称PDT)と呼ばれている。
時刻設定を行うためには、下記の2つのクロックを意識する必要がある。
・システムクロック
PC上の時刻は、システムクロックによって管理されており、ファイルやフォルダのタイムスタンプや、時計やカレンダーの表示の際に利用される。
このシステムクロックは、メモリ上で管理されているため、OSのシャットダウンによって消滅してしまう。
そこで、電源を切っても時刻情報を維持し続けるためにハードウェアクロックが存在し、マザーボード上でバックアップ電池等により動き続けている。
・ハードウェアクロック
システムクロックの説明の際に記載したように、マザーボードで管理されている時刻情報であり、PCの電源を切っても動き続ける。
秒、分、時、曜日、月、年といった時刻情報をバイトデータで保持しているが、タイムゾーンを識別するための情報は保持しておらず、OS側でその解釈を行っている。
その解釈は、/etc/sysconfig/clockファイルによって行われている。
ハードウェアクロックのことを考えると、/etc/localtimeの修正だけでなく、/etc/sysconfig/clockの修正も必要なようだ。
cp /usr/share/zoneinfo/Japan /etc/localtime
vi /etc/sysconfig/clcok
ZONE="Asia/Tokyo"
date
Sun Nov 15 23:53:02 JST 2015
これで正しい時刻を表示することができた。
参考
今回の記事を書くにあたって参考・引用させて頂いたブログなど。
Oracleインストール前の準備作業-11gR2 CentOS6.7(その2)
個人的なメモ書きの続き。
OracleDatabase11gR2をインストールするために行った作業を、引き続き記載していく。
ホスト名の設定
ホスト名の確認および設定する場合の手順を示す。
1.ホスト名の確認
以下のコマンドで、ホスト名を確認できる。
hostname
localhost.localdomain
2.ホスト名の設定
networkを編集して、ホスト名を変更する。
vi /etc/sysconfig/network
HOSTNAME=[ホスト名]
3.hostsファイルの編集
networkで設定したホスト名をhostsファイルに反映する。
vi /etc/hosts
127.0.0.1 localhost [ホスト名]
4.networkを再起動
/etc/rc.d/init.d/network resatart
Shutting down interface eth0: Device state: 3 (disconnected)
[ OK ]
Shutting down interface eth1: [ OK ]
Shutting down loopback interface: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface eth0: Active connection state: activating
Active connection path: /org/freedesktop/NetworkManager/ActiveConnection/2
state: activated
Connection activated [ OK ]
カーネルパラメータの設定
Oracle Databaseのインストールのために、カーネルパラメータを設定する。
/etc/sysctl.confを編集し、sysctl -pで編集内容を反映する。
グループ・ユーザの追加
マニュアルに沿って、グループ・ユーザを追加。
groupadd -g [グループID] [グループ名]
useradd -u [ユーザID] [ユーザ名] -g [プライマリグループ] -G [セカンダリグループ]
追加したグループ・ユーザの確認は以下のコマンドで。
cat /etc/group
cat /etc/passwd
その他
インストールに必要なディレクトリの作成やリソース制限の設定など。
Transparent HugePagesを無効化する
Oracle Database 11g R2では、透過的なHugePagesを無効化する必要があるらしい。
※ 12cのインストレーションガイドでは、そのような記述を見つけられなかったので、要調査
無効化するための手順をメモ。
そもそもTransparent HugePageとは?
メモリとは、pagesとよばれるブロックで管理されており、1pageは4096byteである。そのため、メモリ1MBは256pagesに該当する。
この各pageは、PTE(Page Table Entry)を参照し、仮想アドレスと物理アドレスのマッピング情報を格納しているのだが、最近の大容量メモリの利用により、このマッピング情報が肥大化し、メモリが枯渇することがあるらしい。
※ 詳細は以下が詳しい。
大容量メモリに潜むメモリ枯渇問題その1 ~Linux HugePageの薦め~ | 技術ブログ| レック・テクノロジー・コンサルティング株式会社
大容量メモリに潜むメモリ枯渇問題その2 ~Linux HugePageの薦め~ | 技術ブログ| レック・テクノロジー・コンサルティング株式会社
大容量メモリに潜むメモリ枯渇問題その3 ~Linux HugePageの薦め~ | 技術ブログ| レック・テクノロジー・コンサルティング株式会社
大容量メモリに潜むメモリ枯渇問題その4 ~Linux HugePageの薦め~ | 技術ブログ| レック・テクノロジー・コンサルティング株式会社
大容量メモリに潜むメモリ枯渇問題最終回 ~Linux HugePageの薦め~ | 技術ブログ| レック・テクノロジー・コンサルティング株式会社
そこでメモリ枯渇を防ぐために、page sizeを拡大し、PTEのサイズを小さくするために利用されるのが、Huge pagesとなる。Hugepagesでは1pageあたり2MB(変更できるのかは、未確認)のサイズのブロックとなる。
Huge pagesの設定は、起動時に割り当てる必要があるのだが、そのHuge pagesの作成・管理・使用の多くを自動化する抽象化レイヤーがTransparent HugePage(透過的なHuge Pages)となる。
ちなみに、HugePagesを利用時自動メモリ管理を使用することができず、代わりに自動共有メモリ管理を利用することになる。
Transparent HugePageの確認方法
Red Hat Enterprise Linuxカーネルの場合:
# cat /sys/kernel/mm/redhat_transparent_hugepage/enabled
その他のカーネルの場合:
# cat /sys/kernel/mm/transparent_hugepage/enabled
上記のコマンドを実行すると、以下のような結果が表示される。
ここでは、透過的なHugepPagesを使用している例を示す。
[always] madvise never
Transparent HugePages無効化の方法
Transparent HugePagesを無効化するには、下記の手順を踏む。
1./etc/rc.localの編集
vi /etc/rc.localで下記を追加する
※ CentOS6.7では、/etc/grub.confにtransparent_hugepage=neverを
※ Transparent HugePageを無効化できなかった
/boot/grub/grub.conf ファイルのカーネルコマンドラインに "transparent_hugepage=never" を追加しても、transparent hugepages (THP) を無効にすることができません。
Red Hat Enterprise Linux 6 で THP (transparent hugepages) を無効にしても有効にならない - Red Hat Customer Portal
2.再起動する
再起動後、確認を行うと、以下のようになっており、Transparent HugePageが無効化されている。
always madvise [never]
Linuxユーザにおけるリソース制限(limit.conf)
またまたOracle Database設計関連の記事。
Oracle Databaseをインストールする際に、リソース制限が必要になるらしいので、調べたことのメモ。
limits.conf
oracleユーザおよびgridユーザのリソース制限を行うために、limits.confの内容を確認する。
limits.confとは、PAM認証モジュールの一つであるpam_limits.soの設定ファイルとのことで、下記のようなフォーマットで記述する。
<domain> <type> <item> <value>
各項目の内容は、次のようになっている。
domain:制限を行うユーザ・グループ等
ユーザ名
@グループ名
* デフォルト設定
type:最大値
hard リミットの最大値(root権限で変更可)
soft デフォルトの最大値(ユーザ権限で変更可)
※ soft ~ hardがユーザ権限で変更可能な範囲
item:制限する項目
memlock 占有可能なメモリスペース(KB)
nofile 開くことができる最大ファイル数
stack スタック(メモリ)最大サイズ (KB)
nproc 最大プロセス数
value:閾値
各項目は、下記により詳細な記載がある。
Linuxhack.jp » ユーザ・グループのリソース制限
例えば、次のような設定がされていた場合、TFユーザの最大プロセス実行数は15となり、15を超えるプロセスは強制的に停止させられる。さらにhardが20に設定されていることから、TFユーザはulimitコマンドを使用することで、最大20までプロセスの実行数を増やすことができる。
TF soft nproc 15
TF hard nproc 20
一方で、次のような設定の場合はユーザ単位ではなく、グループ単位での設定となる。
@student soft nproc 20
@student hard nproc 30
ただし、サーバプロセスをlimits.confで管理しようとすると、ハマることがあるらしい。
※ この辺については、要勉強。。。
つまり、「PAM認証を介さないようなdaemon系プログラムの制限には/etc/security/limits.confは使えない」ことになるのです。
sysctl.conf
その他、Linuxのカーネルパラメータの設定を行う際に、編集するファイルについてもメモ。
vi /etc/sysctl.conf
# Kernel sysctl configuration file for Red Hat Linux
#
# For binary values, 0 is disabled, 1 is enabled. See sysctl(8) and
# sysctl.conf(5) for more details.
# Controls IP packet forwarding
net.ipv4.ip_forward = 0
# Controls source route verification
net.ipv4.conf.default.rp_filter = 1
# Do not accept source routing
net.ipv4.conf.default.accept_source_route = 0
# Controls the System Request debugging functionality of the kernel
kernel.sysrq = 0
# Controls whether core dumps will append the PID to the core filename.
# Useful for debugging multi-threaded applications.
kernel.core_uses_pid = 1
参考・引用
参考・引用させて頂いたブログ・記事を記載させて頂きます。
ディスクI/Oスケジューラの設定
今、仕事でDBの設計を行っているのだが、OS周りのチューニングが色々と必要らしい。例えば、LinuxのディスクI/Oスケジューラというものも設定が必要とのこと。
つまり、ディスクI/Oが発生した際に、HDDヘッドがランダムに移動すること防ぎ、ディスクのシーク量を減少させることが目的のようだ。
今回は、ディスクI/Oスケジューラについて、調べた内容をメモ書きとして残しておく。
ディスクI/Oスケジューラ
ディスクI/Oスケジューラとは、アプリケーションなどから発行された複数のI/O要求を並び変えるソフトウェアを指す。
OSからI/O要求が新規に追加された際には、I/Oスケジューラが呼び出されるようになっており、新しい要求をキューに追加する。
このとき、要求をキューに追加するアルゴリズムとして、次の4つが存在する。
noop
最もシンプルなスケジューラで、I/O要求を単純に要求順に処理する。
noopはスケジューリング負荷が小さく、ランダムアクセスが高速なハードウェアに適していると考えられている。
deadline
ディスク上で位置が近いI/O要求を優先して処理を行うことで、HDDヘッドの移動量を削減する。位置が近いI/O要求を優先するため、HDDヘッドから遠くにあるI/O要求は後回しされるが、待ち時間の限界値(deadline)より長く待たされているI/O要求が発生した際には、そのI/O要求を優先する。
deadlineの設定によりレイテンシの上限が保証されるため、リアルタイムアプリケーションやデータベース管理に適していると言われている。
anticipatory(AS)
I/O要求を予測し、その予測に基づいて処理を行う。位置が近い場所へのI/Oがすぐ後に発行されると予測 した場合、I/O要求の処理を遅延させ、近隣のI/O要求が発行されるのを待ってから、I/O要求の処理を行う。つまり、いくつかのI/O要求を貯めてから処理を行う性質がある。
ただしDeadlineと同様に、待ち時間の長いI/O要求が発生した場合にはI/O待ちを中断し、待ち時間の長いI/O要求を優先して処理する。
anticipatoryは、データにシーケンシャルにアクセスするWebサーバなどに有効とされている。
cfq(Completely Fair Queuing)
スケジューラは内部に多数のキューを保持しておき、プロセス単位でI/O要求をそれらキューに割り振っていく。処理対象のキューを一定間隔で切り替えることで、プロセス間でI/O要求は公平に処理されていく。
また、Deadlineやanticipatoryと同様に待ち時間の長いI/O要求が存在した場合、それを優先的に処理していく。
Oracle 12cでの設定
Oracle社提供のマニュアルによると、OracleのASMのパフォーマンス向上のために、Deadline I/Oスケジューラを使用することが推奨されているようだ。
スケジューラの確認方法
スケジューラの確認は、以下のコマンドで行える。
cat /sys/block/sda/queue/scheduler
noop anticipatory deadline [cfq]
このうち[]で囲まれているものが現在の設定値となる。
スケジューラを変更したい場合は、下記のコマンドで変更できる。
echo noop > /sys/block/sda/queue/scheduler
cat /sys/block/sda/queue/scheduler
[noop] anticipatory deadline cfq
ただし、上記は一時的 な変更であるため、恒久的な変更を行うためにはカーネル引数として以下を設定する。
elevator=変更したいアルゴリズム
※ elevator=deadlineなど
参考・引用
以下、参考・引用させて頂いたブログ・記事など
OSSはアルミニウムの翼で飛ぶ: RHEL I/Oスケジューラの変更
・仮想化環境におけるI/Oスケジューラの動作と性能に関する考察
http://www.internetconference.org/ic2010/PDF/ic2010-session-1-3.pdf