AWSサブネット内で利用できるIPアドレス数

AWSサブネットでは最初の4つのIPアドレスと最後のIPアドレスは使用できない。

※10.0.0.0/24の場合

10.0.0.0: ネットワークアドレス
10.0.0.1: VPCルータ用(AWS予約IP)
10.0.0.2: DNSサーバで利用(AWS予約IP)
10.0.0.3: 将来の利用のためにAWSで予約(AWS予約IP)
10.0.0.255: ブロードキャストアドレス

サブネットで利用可能なIPアドレス数はこれら5つのIPアドレスを引いた数になる。

CIDR毎に利用可能なIPアドレス

CIDR IPアドレス範囲 利用可能なIPアドレス
/16 10.0.0.0~10.0.255.255 65531個(65536-5)
/17 10.0.0.0~10.0.127.255 32763個(32768-5)
/18 10.0.0.0~10.0.63.255 16379個(16384-5)
/19 10.0.0.0~10.0.31.255 8187個(8192-5 )
/20 10.0.0.0~10.0.15.255 4091個(4096-5)
/21 10.0.0.0~10.0.7.255 2043個(2048-5)
/22 10.0.0.0~10.0.3.255 1019個(1024-5)
/23 10.0.0.0~10.0.1.255 507個(512-5)
/24 10.0.0.0~10.0.0.255 251個(256-5)
/25 10.0.0.0~10.0.0.127 123個(128-5)
/26 10.0.0.0~10.0.0.63 59個(64-5)
/27 10.0.0.0~10.0.0.31 27個(32-5)
/28 10.0.0.0~10.0.0.15 11個(16-5)
/29 10.0.0.0~10.0.0.7 3個(8-5)

よく使うpacemakerのコマンド

よく使うpacemakerのコマンドをメモ。

運用でよく使うコマンド

クラスタ起動

pcs cluster start --all

ステータス確認

pcs status

リソースの詳細確認

pcs resource show <リソース名>

リソースの制約確認

pcs constraint

リソース実行阻止の制約を除去

pcs resource clear <リソース名>

メンテナンスモード(すべてのリソースをunmanaged)

pcs property set maintenance-mode=true

メンテナンスモード解除

pcs property set maintenance-mode=false

ノードスタンバイ

pcs cluster standby <ノード名>

ノードスタンバイ解除

pcs cluster unstandby <ノード名>

ノード停止

pcs cluster stop <ノード名>

フェールオーバ

pcs resource move <リソースID>

リソース無効化

pcs resource disable <リソース名>

リソース有効化

pcs resource enable <リソース名>

リソース削除

pcs resource delete <リソース名>

構築でよく使うコマンド

各ノード間の認証確立

pcs cluster auth <ノード1> <ノード2>

クラスタ構成

pcs cluster setup --name <クラスタ名> <ノード1> <ノード2>

リソースグループ作成

pcs resource group add <リソースグループ名> <リソース名> <リソース名>

リソースのノード実行優先順位設定

pcs constraint location <リソース名> prefers <クラスタ名>=<スコア値>

<リソース1>を常に<リソース2>と同じマシンで実行する。

pcs constraint colocation add <リソース1> with <リソース2> score=INFINITY

リソースの起動順番設定 <リソース1> ⇒ <リソース2>

pcs constraint order start <リソース1> then start <リソース2>

リソースの停止順番設定 <リソース1> ⇒ <リソース2>

pcs constraint order stop <リソース1> then stop <リソース2>

クラスタの数が必要最低限に達していない場合でも、特別な動作は行わない

pcs property set no-quorum-policy=ignore

自動フェイルバックを無効にする。

pcs property set default-resource-stickiness="INFINITY"

GrafanaでJavaヒープ使用率のパネルを作る

jmxtransというツールでJavaのメトリックを取得して、Grafanaでパネル表示させてみました。

構成はこんな感じ
f:id:hmen:20200924184503p:plain

1. jmxtransインストール

rpmでインストールしました。
パッケージのダウンロードやインストール方法はこちらで。
https://github.com/jmxtrans/jmxtrans/wiki/Installation

2. jsonファイルを準備

apserver01への接続方法と、メトリックの格納方法をファイルに書きます。

{
  "servers" : [ {
    "port" : "39999",                            # JMXポート
    "host" : "apserver01",                       # APサーバのホスト名
    "queries" : [ {
      # Java Heap
      "outputWriters" : [ {
        "@class" : "com.googlecode.jmxtrans.model.output.InfluxDbWriterFactory",
        "url" : "http://192.168.10.1:8086/",         # 格納先influxdbのURL
        "username" : "admin",                        # influxdbのユーザ名
        "password" : "admin",                        # influxdbのパスワード
        "database" : "influxdb",                     # 格納先DB名
        "tags"     : {"application" : "ap01"}        # メトリックのタグ
      } ],
      "obj" : "java.lang:type=Memory",                      # オブジェクトタイプ
      "resultAlias":"jvmMemory",                            # Alias
      "attr" : [ "HeapMemoryUsage", "NonHeapMemoryUsage" ]  # 属性
    },{
  } ]
}


オブジェクトタイプや属性は、事前にjconsole等で確認しておくといい。

f:id:hmen:20200924184322p:plain

オブジェクトタイプ、属性が複数ある場合、(例えばJavaHeap以外にもThreadPoolやold、new領域等を取得したい場合)は、
以下のようにオブジェクト毎に並べて記述する。
※まとめて記述する方法があるかもしれません。。。

{
  "servers" : [ {
    "port" : "39999",
    "host" : "apserver01",
    "queries" : [ {
      "outputWriters" : [ {
        "@class" : "com.googlecode.jmxtrans.model.output.InfluxDbWriterFactory",
        "url" : "http://192.168.10.1:8086/", 
        "username" : "admin",
        "password" : "admin",
        "database" : "influxdb",
        "tags"     : {"application" : "ap01"}
      } ],
      "obj" : "java.lang:type=Memory",
      "resultAlias":"jvmMemory",
      "attr" : [ "HeapMemoryUsage", "NonHeapMemoryUsage" ]
    },{
      "outputWriters" : [ {
        "@class" : "com.googlecode.jmxtrans.model.output.InfluxDbWriterFactory",
        "url" : "http://192.168.10.1:8086/", 
        "username" : "admin",
        "password" : "admin",
        "database" : "influxdb",
        "tags"     : {"application" : "ap01"}
      } ],
      "obj" : "java.lang:type=GarbageCollector,name=*",
      "resultAlias": "jvmMemory",
      "attr" : [ "CollectionCount", "CollectionTime" ]
    },{
      "outputWriters" : [ {
        "@class" : "com.googlecode.jmxtrans.model.output.InfluxDbWriterFactory",
        "url" : "http://192.168.10.1:8086/", 
        "username" : "admin",
        "password" : "admin",
        "database" : "influxdb",
        "tags"     : {"application" : "ap01"}
      } ],
      "obj" : "java.lang:name=CMS Old Gen,type=MemoryPool",
      "resultAlias": "cmsoldgen",
      "attr" : [ "Usage" ]
    },{
      "outputWriters" : [ {
        "@class" : "com.googlecode.jmxtrans.model.output.InfluxDbWriterFactory",
        "url" : "http://192.168.10.1:8086/", 
        "username" : "admin",
        "password" : "admin",
        "database" : "influxdb",
        "tags"     : {"application" : "ap01"}
      } ],
      "obj" : "java.lang:type=MemoryPool,name=Par Eden Space",
      "resultAlias": "edengen",
      "attr" : [ "Usage" ]
    },{
      "outputWriters" : [ {
        "@class" : "com.googlecode.jmxtrans.model.output.InfluxDbWriterFactory",
        "url" : "http://192.168.10.1:8086/", 
        "username" : "admin",
        "password" : "admin",
        "database" : "influxdb",
        "tags"     : {"application" : "ap01"}
      } ],
      "obj" : "java.lang:type=MemoryPool,name=Par Survivor Space",
      "resultAlias": "survivorgen",
      "attr" : [ "Usage" ]
    },{
      "outputWriters" : [ {
        "@class" : "com.googlecode.jmxtrans.model.output.InfluxDbWriterFactory",
        "url" : "http://192.168.10.1:8086/", 
        "username" : "admin",
        "password" : "admin",
        "database" : "influxdb",
        "tags"     : {"application" : "ap01"}
      } ],
      "obj" : "java.lang:type=MemoryPool,name=CMS Perm Gen",
      "resultAlias": "cmspermgen",
      "attr" : [ "Usage" ]
    },{
      "outputWriters" : [ {
        "@class" : "com.googlecode.jmxtrans.model.output.InfluxDbWriterFactory",
        "url" : "http://192.168.10.1:8086/", 
        "username" : "admin",
        "password" : "admin",
        "database" : "influxdb",
        "tags"     : {"application" : "ap01"}
      } ],
      "obj" : "java.lang:type=Threading",
      "resultAlias": "jvmMemory",
      "attr" : [ "DaemonThreadCount", "PeakThreadCount", "ThreadCount", "TotalStartedThreadCount" ]
    } ]
  } ]
}


作成したファイルはファイル名を<適用な名前>.jsonとして、以下に配置する。
/var/lib/jmxtrans/

(3) jmxtransを起動

# /etc/init.d/jmxtrans start
Starting JmxTrans...

起動失敗したらconfigが間違ってると思います。

(4) Grafanaパネル作成

パネルのQuery設定で、SQLを書きます。

事前に以下のようにVariablesを設定しておきます。
f:id:hmen:20200924185247p:plain

以下は参考のSQLです。これはJavaヒープサイズのMAX値(-Xmx)を取得するものです。
SELECT mean("HeapMemoryUsage_max") FROM "autogen"."jvmMemory" WHERE ("hostname" =~/^$host$/ AND "application" =~ /^$host$ AND "application" =~ /^$app$/) AND $timeFilter GROUP BY time($inter_val) fill(none)

SQLをパネルのQuery設定に記述
f:id:hmen:20200924185455p:plain

Javaヒープ使用率のパネルができました。

f:id:hmen:20200924193222p:plain

同じようにJavaヒープ以外もパネルにして、並べて表示。
f:id:hmen:20200924185524p:plain

influxDBのbackup、join

influxDBのデータをバックアップして、別のinfluxDBにjoinするシェルを作りました。

backupコマンド

開始日時、終了日時などを指定

influxd backup -portable -database "<DB名>" -start <timestamp> -end <timestamp> -host <DBhost> <backuppath>


joinコマンド

<リストア用DB>は一時DBなので、適用な名前をつける。
一時DBにリストアして、データを既存DBにjoinする感じ。

influxd restore -portable -db <DB名> -newdb <リストア用DB名> <backupfile>
influx -database '<リストア用DB名>' -execute 'SELECT * INTO <DB名>..:MEASUREMENT FROM /.*/ GROUP BY *'
influx -database '<リストア用DB名>' -execute 'DROP DATABASE <リストア用DB名>'


シェルにするとこんな感じ。

cronで日時処理してます。
backup

predate=`date -u "+%Y-%m-%dT%H:%M:%SZ" --date '1 day ago'`
enddate=`date -u "+%Y-%m-%dT%H:%M:%SZ"`
dbhost=192.168.10.10:8088
bkpath=/etc/influxdb/mysnap

influxd backup -portable -database "telegraf" -start $predate -end $enddate -host $dbhost $bkpath


join

bkfile=/etc/influxdb/mysnap/`date +%Y%m%d`/telegraf

influxd restore -portable -db telegraf -newdb telegraf_bak $bkfile
influx -database 'telegraf_bak' -execute 'SELECT * INTO telegraf..:MEASUREMENT FROM /.*/ GROUP BY *'
influx -database 'telegraf_bak' -execute 'DROP DATABASE telegraf_bak'


もっと効率の良いやり方があるかもしれません・・。

influxDBのretention policyを設定する

経緯

influxdbのretention policyの設定コマンドをいつも忘れてしまうので、メモ
influxdbはGrafana用に使用してます。

設定

# influx
Connected to http://localhost:8086 version 1.7.6
InfluxDB shell version: 1.7.6
Enter an InfluxQL query


> show databases
name: databases
name
----
_internal
telegraf


DBを選択
> use telegraf
Using database telegraf


retention policyの設定確認
> show retention policies
name    duration  shardGroupDuration replicaN default
----    --------  ------------------ -------- -------
autogen 2160h0m0s 168h0m0s           1        true


durationの変更コマンド

alter retention policy <ポリシー名> ON <DB名> duration <値>

> alter retention policy autogen ON telegraf duration 2150h
>
> show retention policies
name    duration  shardGroupDuration replicaN default
----    --------  ------------------ -------- -------
autogen 2150h0m0s 168h0m0s           1        true


shard groupを変更する場合

alter retention policy <ポリシー名> ON <DB名> shard Duration <値>

> alter retention policy autogen ON telegraf shard Duration 150h
>
> show retention policies
name    duration  shardGroupDuration replicaN default
----    --------  ------------------ -------- -------
autogen 2160h0m0s 150h0m0s           1        true
>


ソースIPアドレスを指定してsshする

経緯

HA構成のサーバから他のサーバにsshする際、ソースIPをVIPにする必要があったのでメモ

設定

sshのオプションで-o bindaddress=<ソースIPアドレス>を使えばいいらしい

host1からhost2へのsshを試してみます。
host1:10.0.0.10(rip)、10.0.0.20(vip)
host2:10.0.0.30(rip)

普通にsshした場合

[root@host1 ~]# ssh root@10.0.0.30
Last login: Wed Sep  9 21:37:08 2020 from 10.0.0.10
[root@host2 ~]#


host2の/var/log/secureを見ると、接続元は「10.0.0.10」

Sep  9 21:44:20 host1 sshd[13344]: Connection from 10.0.0.10 port 55155 on 10.0.0.30 port 22


ソースIPを変えてsshした場合

[root@host1 ~]# ssh -o bindaddress=10.0.0.20 root@10.0.0.30
Last login: Wed Sep  9 21:48:49 2020 from 10.0.0.20
[root@host2 ~]#


接続元がvipである「10.0.0.20」になりました。

Sep  9 21:50:09 host1 sshd[13774]: Connection from 10.0.0.20 port 41473 on 10.0.0.30 port 22



マシンに無いアドレスを指定するとエラー

[root@host1 ~]# ssh -o bindaddress=10.0.0.40 root@10.0.0.30
bind: 10.0.0.40: Cannnot assign requested address


sftpでも使えます。

[root@host1 ~]# sftp -o bindaddress=10.0.0.10 10.0.0.30
Connecting to 10.0.0.30...
sftp>


systemdの自動再起動について

経緯

Systemdの自動再起動オプションの中で、RestartForceExitStatusがよく分からなかったのでRestartと合わせて検証した。

man

RestartForceExitStatus=
Takes a list of exit status definitions that, when returned by the main service process, will force automatic service restarts, regardless of the restart setting configured with Restart=. The argument format is similar to RestartPreventExitStatus=.

Restart =の設定値に関係なく、サービスの自動再起動を強制できるらしい。

検証

rsyslogのunitファイルで検証してみます。
/usr/lib/systemd/system/rsyslog.service

Restart

まずはRestart=alwaysの動きを見てみる。
Serviceセクションを以下のように変更。

[Service]
Type=notify
Restart=always
EnvironmentFile=-/etc/sysconfig/rsyslog
ExecStart=/usr/sbin/rsyslogd -n $SYSLOGD_OPTIONS
UMask=0066
StandardOutput=null


systemdステータスからpidを確認

# systemctl status rsyslog
● rsyslog.service - System Logging Service
   Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2020-09-02 23:41:50 PDT; 6h ago
     Docs: man:rsyslogd(8)
           http://www.rsyslog.com/doc/
 Main PID: 90210 (rsyslogd) 
    Tasks: 3
   Memory: 1.0M
   CGroup: /system.slice/rsyslog.service
           mq90210 /usr/sbin/rsyslogd -n


pidを指定してkill

# kill 90210


pidが変わってるので再起動された。

# systemctl status rsyslog
● rsyslog.service - System Logging Service
   Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2020-09-03 05:53:25 PDT; 1min 35s ago
     Docs: man:rsyslogd(8)
           http://www.rsyslog.com/doc/
 Main PID: 112674 (rsyslogd)
    Tasks: 3
   Memory: 716.0K
   CGroup: /system.slice/rsyslog.service
           mq112674 /usr/sbin/rsyslogd -n


RestartForceExitStatus

RestartForceExitStatusはシグナル名かシグナルIDを指定するらしい。
今回はSIGSEGVでやってみる。

[Service]
Type=notify
RestartForceExitStatus=SIGSEGV
EnvironmentFile=-/etc/sysconfig/rsyslog
ExecStart=/usr/sbin/rsyslogd -n $SYSLOGD_OPTIONS
UMask=0066
StandardOutput=null


先ほどと同じようにpidを確認

# systemctl status rsyslog
● rsyslog.service - System Logging Service
   Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2020-09-03 06:39:09 PDT; 4min 22s ago
     Docs: man:rsyslogd(8)
           http://www.rsyslog.com/doc/
 Main PID: 116314 (rsyslogd)
   CGroup: /system.slice/rsyslog.service
           mq116314 /usr/sbin/rsyslogd -n


SIGSEGVでkill

kill -s SIGSEGV 116314


pidが変わってるので再起動された

# systemctl status rsyslog
● rsyslog.service - System Logging Service
   Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2020-09-03 06:44:17 PDT; 11s ago
     Docs: man:rsyslogd(8)
           http://www.rsyslog.com/doc/
 Main PID: 116683 (rsyslogd)
    Tasks: 3
   Memory: 792.0K
   CGroup: /system.slice/rsyslog.service
           mq116683 /usr/sbin/rsyslogd -n


Restart + RestartForceExitStatus

RestartとRestartForceExitStatusを組み合わせることもできるらしい。

[Service]
Restart=on-success
RestartForceExitStatus=SIGSEGV
Type=notify
EnvironmentFile=-/etc/sysconfig/rsyslog
ExecStart=/usr/sbin/rsyslogd -n $SYSLOGD_OPTIONS
UMask=0066
StandardOutput=null


Restart=on-successは正常終了(終了コード0)した場合に再起動するオプション。
このように正常終了かつSIGSEGVが発生した場合に再起動する、といった柔軟なこともできるらしい。

pid確認

# systemctl status rsyslog
● rsyslog.service - System Logging Service
   Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2020-09-03 06:39:09 PDT; 4min 22s ago
     Docs: man:rsyslogd(8)
           http://www.rsyslog.com/doc/
 Main PID: 116314 (rsyslogd)
   CGroup: /system.slice/rsyslog.service
           mq116314 /usr/sbin/rsyslogd -n


SIGSEGVでkill

kill -s SIGSEGV 116314


再起動された。

# systemctl status rsyslog
● rsyslog.service - System Logging Service
   Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2020-09-03 06:44:17 PDT; 11s ago
     Docs: man:rsyslogd(8)
           http://www.rsyslog.com/doc/
 Main PID: 116683 (rsyslogd)
    Tasks: 3
   Memory: 792.0K
   CGroup: /system.slice/rsyslog.service
           mq116683 /usr/sbin/rsyslogd -n