2017年5月26日金曜日

GraylogのElasticsearchのデータを削除する ("Elasticsearch cluster unhealthy (RED)"のエラーを解消する②)

前回、Graylogのディスク拡張を実施したが、以下Elasticsearchのエラーは解消されない状態となっていた。

------------------------------
Elasticsearch cluster unhealthy (RED)
The Elasticsearch cluster state is RED which means shards are unassigned. This usually indicates a crashed and corrupt cluster and needs to be investigated.

~(以下略)~
------------------------------

この状態ではGraylogで受信したログの検索ができない状態となるため、どうにかして復旧する必要があった。復旧までの手順をこらより記載するが、先に言っておくと、Elasticsearchのデータを消すことによって対処をした(復旧というより初期化という表現が近いかもしれない)。

大活躍するcurlコマンド

Elasticsearchでは、各種URLにHTTPアクセスをすると、結果を返したり、設定をしたりすることができる。どうもこれがREST APIと呼ばれるものらしいが、とにかくまずは各種確認をしてみることにした。

この際に利用できるコマンドがcurlコマンドである。client for URLの略(?)で、カールと呼ぶようだ。このコマンドでHTTPリクエストを送るとHTTPレスポンスを受けることができる。

例えば、Elasticsearchの状態確認は以下コマンドで実行できる。

◆Elasticsearchの状態確認
# curl -XGET http://192.168.11.151:9200/_cluster/health?pretty=true
------------------------------
{
  "cluster_name" : "graylog",
  "status" : "red",
  "timed_out" : false,
  "number_of_nodes" : 2,
  "number_of_data_nodes" : 1,
  "active_primary_shards" : 2,
  "active_shards" : 2,
  "relocating_shards" : 0,
  "initializing_shards" : 2,
  "unassigned_shards" : 4,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 25.0
}
------------------------------

上記下線部にて、冒頭のエラーと同様に、statusが"red"となっていることがわかる。

さて、このコマンドで各種確認をしてみる。まずはNodeとShardの状態を確認。

◆Nodeの確認
# curl -XGET http://192.168.11.151:9200/_node/cat/nodes
------------------------------
192.168.11.151 192.168.11.151 24 82 3.12 d * Manbot
192.168.11.151 192.168.11.151 46 82 3.12 c - graylog-bbbebd4f-8c8b-406a-8a33-b51f00e6facc
------------------------------

◆Shardの確認
# curl -XGET http://192.168.11.151:9200/_cat/shards
------------------------------
graylog_0 3 p STARTED      1633383 439.5mb 192.168.11.151 Manbot
graylog_0 3 r UNASSIGNED                                      
graylog_0 1 p INITIALIZING                 192.168.11.151 Manbot
graylog_0 1 r UNASSIGNED                                      
graylog_0 2 p STARTED      1632406 438.6mb 192.168.11.151 Manbot
graylog_0 2 r UNASSIGNED                                      
graylog_0 0 p INITIALIZING                 192.168.11.151 Manbot
graylog_0 0 r UNASSIGNED                                      
------------------------------

下線部が"STARTED"ではなく、"INITIALIZING"となっているのがあやしい…。

もっと詳細な状態確認は以下コマンドで実施する。

◆詳細状態確認
# curl -XGET http://192.168.11.151:9200/_cluster/state?pretty=true
------------------------------
{
  "cluster_name" : "graylog",
  "version" : 131,
  "state_uuid" : "-R-stME1QAK2WkC4kZS6tQ",
  "master_node" : "GKmS2bPySZ69oHVcxwbTqg",
  "blocks" : { },
  "nodes" : {
    "GKmS2bPySZ69oHVcxwbTqg" : {
      "name" : "Orphan-Maker",
      "transport_address" : "192.168.11.151:9300",
      "attributes" : { }
    },
    "U9D_Bp0NTpKauX89rKWsvg" : {
      "name" : "graylog-bbbebd4f-8c8b-406a-8a33-b51f00e6facc",
      "transport_address" : "192.168.11.151:9350",
      "attributes" : {
        "client" : "true",
        "data" : "false",
        "master" : "false"
      }
    }
  },

~(中略)~

            "state" : "INITIALIZING",
            "primary" : true,
            "node" : "GKmS2bPySZ69oHVcxwbTqg",
            "relocating_node" : null,
            "shard" : 1,
            "index" : "graylog_0",
            "version" : 36,
            "allocation_id" : {
              "id" : "JFJ78yB9Qf6o6s9TfOnrbw"
            },
            "unassigned_info" : {
              "reason" : "ALLOCATION_FAILED",
              "at" : "2017-05-12T14:37:29.179Z",
              "details" : "failed recovery, failure IndexShardRecoveryException[failed to recovery from gateway]; nested: EngineCreationFailureException[failed to recover from translog]; nested: EngineException[failed to recover from translog]; nested: ElasticsearchException[unexpected exception reading from translog snapshot of /var/opt/graylog/data/elasticsearch/graylog/nodes/0/indices/graylog_0/1/translog/translog-855.tlog]; nested: EOFException[read past EOF. pos [532245] length: [4] end: [532245]]; "
            }
          },

~(以下略)~
------------------------------

"INITIALIZING"の理由が記載されているような気がするが、、、残念ながら、これを見ても解決方法はよくわからなかった。

データを消して復旧

結局直し方がよくわからず、最終手段として過去データを削除してみることにした。

まず"Index"の状態を確認する。これはいわばElasticsearchのデータが蓄えられるデータベース領域のようなものである。

◆Indexの確認
# curl -XGET http://192.168.11.151:9200/_cat/indices
------------------------------
red open graylog_0 4 1 3265789 0 878.1mb 878.1mb
------------------------------

現在は878MBを使っている模様。以下コマンドでデータを削除する。

◆データを削除
# curl -XDELETE http://192.168.11.151:9200/graylog_0
------------------------------
{"acknowledged":false}
------------------------------

再度、Indexの確認をする。

◆Indexの確認
# curl -XGET http://192.168.11.151:9200/_cat/indices
------------------------------
red open graylog_0 4 1 0 0 390b 390b
------------------------------

容量が390Bに減少していることがわかる。ディスク使用量を確認してみる。

# df -h
------------------------------
Filesystem      Size  Used Avail Use% Mounted on
udev            2.0G  4.0K  2.0G   1% /dev
tmpfs           396M  692K  395M   1% /run
/dev/dm-0        15G  2.7G   12G  19% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
none            5.0M     0  5.0M   0% /run/lock
none            2.0G     0  2.0G   0% /run/shm
none            100M     0  100M   0% /run/user
/dev/sda1       236M   74M  150M  34% /boot
/dev/sdb1        40G  805M   37G   3% /var/opt/graylog/data
------------------------------

もともと11GBあったデータが805MBまで減ったことがわかる。

これで一度Shardの状態を確認する

◆Shardの確認
# curl -XGET http://192.168.11.151:9200/_cat/shards
------------------------------
graylog_0 3 p STARTED    0 130b 192.168.11.151 Manbot
graylog_0 3 r UNASSIGNED                            
graylog_0 1 p STARTED    0 130b 192.168.11.151 Manbot
graylog_0 1 r UNASSIGNED                            
graylog_0 2 p STARTED    0 130b 192.168.11.151 Manbot
graylog_0 2 r UNASSIGNED                            
graylog_0 0 p UNASSIGNED                            
graylog_0 0 r UNASSIGNED                            
------------------------------

少なくとも"INITIALIZING"となっているShardはいなくなったように見える。一度OSを再起動して再度確認してみる。

◆Shardの確認
# curl -XGET http://192.168.11.151:9200/_cat/shards
------------------------------
graylog_0 2 p STARTED    2701 751.9kb 192.168.11.151 Steve Rogers
graylog_0 2 r UNASSIGNED                                        
graylog_0 3 p STARTED    2531 772.3kb 192.168.11.151 Steve Rogers
graylog_0 3 r UNASSIGNED                                        
graylog_0 1 p STARTED    2579   762kb 192.168.11.151 Steve Rogers
graylog_0 1 r UNASSIGNED                                        
graylog_0 0 p STARTED    2608 751.5kb 192.168.11.151 Steve Rogers
graylog_0 0 r UNASSIGNED                                        
------------------------------

上記の通り、4つのShardが"STARTED"となった。Elasticsearchの状態も確認してみる。

◆Elasticsearchの状態確認
# curl -XGET http://192.168.11.151:9200/_cluster/health?pretty=true
------------------------------
{
  "cluster_name" : "graylog",
  "status" : "yellow",
  "timed_out" : false,
  "number_of_nodes" : 2,
  "number_of_data_nodes" : 1,
  "active_primary_shards" : 4,
  "active_shards" : 4,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 4,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 50.0
}
------------------------------

statusが"yellow"となり"red"よりは解消された。一応この状態であれば、ログの検索は実施できるようではある。さらに"yellow"を"green"にするためには、以下の通り、ReplicaのShardの数を0に設定すればよいようだ。

------------------------------コマンドここから
# curl -XPUT 'http://192.168.11.151:9200/_settings' -d '
{
    "index" : {
        "number_of_replicas" : 0
    }
}'
------------------------------コマンドここまで
------------------------------
{"acknowledged":true}
------------------------------

Shardの状態を確認する。

◆Shardの確認
# curl -XGET http://192.168.11.151:9200/_cat/shards
------------------------------
graylog_0 2 p STARTED 90501 23.6mb 192.168.11.151 Steve Rogers
graylog_0 3 p STARTED 90342 23.5mb 192.168.11.151 Steve Rogers
graylog_0 1 p STARTED 90677 23.6mb 192.168.11.151 Steve Rogers
graylog_0 0 p STARTED 90231 23.5mb 192.168.11.151 Steve Rogers
------------------------------

◆Elasticsearchの状態確認
# curl -XGET http://192.168.11.151:9200/_cluster/health?pretty=true
------------------------------
{
  "cluster_name" : "graylog",
  "status" : "green",
  "timed_out" : false,
  "number_of_nodes" : 2,
  "number_of_data_nodes" : 1,
  "active_primary_shards" : 4,
  "active_shards" : 4,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 0,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 100.0
}
------------------------------

以上でElasticsearchのステータスを"red"から"green"に回復させることができた。しかし、データをすべて消すという、復旧方法としてはかなり乱暴な方法となってしまったので、データを消さずに復旧する方法は引き続き調査したい。

2017年5月19日金曜日

Graylogの仮想アプライアンスでログ保存領域のディスク拡張を実施する ("Elasticsearch cluster unhealthy (RED)"のエラーを解消する①)

自宅環境のログ統合管理のために、仮想アプライアンスのGraylogを導入しているが、先日以下のようなエラーが出てログが収集できなくなってしまった。

------------------------------
Elasticsearch cluster unhealthy (RED)
The Elasticsearch cluster state is RED which means shards are unassigned. This usually indicates a crashed and corrupt cluster and needs to be investigated.

~(以下略)~
------------------------------


Elasticsearchがエラーを吐いているようだ。とりあえず原因切り分けしていこう。

原因切り分け

仮想アプライアンスのGraylogの場合、Elasticsearchの動作ログは以下URLに記載のある通り、/var/log/graylog/elasticsearchにあるようなので、そのディレクトリにあるgraylog.log確認してみる。

http://docs.graylog.org/en/2.2/pages/configuration/file_location.html#id5

# tail /var/log/graylog/elasticsearch/graylog.log
------------------------------
~(省略)~

at org.elasticsearch.index.engine.InternalEngine.recoverFromTranslog(InternalEngine.java:235)
... 12 more
Caused by: java.io.EOFException: read past EOF. pos [532245] length: [4] end: [532245]
at org.elasticsearch.common.io.Channels.readFromFileChannelWithEofException(Channels.java:102)
at org.elasticsearch.index.translog.ImmutableTranslogReader.readBytes(ImmutableTranslogReader.java:84)
at org.elasticsearch.index.translog.TranslogReader.readSize(TranslogReader.java:91)
... 19 more
[2017-05-12 21:34:21,922][WARN ][cluster.routing.allocation.decider] [Cody Mushumanski Gun Man] high disk watermark [90%] exceeded on [6-FCB92qRk2n76qo6h1PSg][Cody Mushumanski Gun Man][/var/opt/graylog/data/elasticsearch/graylog/nodes/0] free: 987.6mb[6.4%], shards will be relocated away from this node
------------------------------

下線部があやしい…。どうもディスク使用率が90%を超えて、ElasticsearchのShardがNodeから除外された、といったメッセージに見える。
※NodeやShardといった単語はElasticsearchの用語となるが、この説明は今回は割愛する

dfでディスク使用率を確認してみる。

# df -h
------------------------------
Filesystem      Size  Used Avail Use% Mounted on
udev            2.0G  4.0K  2.0G   1% /dev
tmpfs           396M  692K  395M   1% /run
/dev/dm-0        15G   14G  981M  94% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
none            5.0M     0  5.0M   0% /run/lock
none            2.0G     0  2.0G   0% /run/shm
none            100M     0  100M   0% /run/user
/dev/sda1       236M   74M  150M  34% /boot
------------------------------

確かに、/のディスク使用率が94%になっている。どうやらディスク使用率が90%を超えると、Graylogの中で動いているElasticsearchは動作を止めてしまうようだ。ということで、ディスク拡張を行い復旧を試みることにした。

なお、先に言っておくと、ディスク拡張自体は成功したが、冒頭のエラーはディスク拡張だけでは解消しなかった。

ディスク拡張手順

ディスク拡張手順は以下にマニュアルが用意されているので、そのまま実施すればよい。解説を加えつつ実施していこう。

http://docs.graylog.org/en/2.2/pages/configuration/graylog_ctl.html#extend-ova-disk

1. 仮想マシンにディスクを追加

ログ保存用のディスクとして、vSphere Clientで仮想ハードディスクを追加する。


2. Graylogを再起動

ディスクを認識させるため、一度再起動しておく。

$ sudo shutdown -r now

3. Graylogのサービスを停止

作業中はGraylogのサービスを停止しておく。

$ sudo graylog-ctl stop
------------------------------
timeout: run: elasticsearch: (pid 861) 83s, want down, got TERM
ok: down: etcd: 0s, normally up
ok: down: graylog-server: 0s, normally up
ok: down: mongodb: 1s, normally up
ok: down: nginx: 0s, normally up
------------------------------

4. ディスクが認識確認

以下コマンドで確認できる。/dev/sdbとして認識していればOK。今回は40GiBのディスクを追加してみた。

$ sudo lshw -class disk
------------------------------
DMI   SMP   PA-RISC       device-tree           SPD   memory      /proc/cpuinfo             CPUID     PCI (sysfs)           ISA PnP       PCMCIA      PCMCIA      kernel device tree (sysfs)                          USB   IDE   SCSI    Network interfaces                  Framebuffer devices                   Display       CPUFreq       ABI     *-disk
       description: SCSI Disk
       physical id: 0.0.0
       bus info: scsi@2:0.0.0
       logical name: /dev/sdb
       size: 40GiB (42GB)
       configuration: sectorsize=512
  *-disk
       description: ATA Disk
       product: VMware Virtual I
       physical id: 0.0.0
       bus info: scsi@0:0.0.0
       logical name: /dev/sda
       version: 0001
       serial: 00000000000000000001
       size: 19GiB (20GB)
       capabilities: partitioned partitioned:dos
       configuration: ansiversion=5 sectorsize=512 signature=000c6ec2
------------------------------

5. ディスクフォーマット

以下3つのコマンドで/dev/sdbのフォーマットを行う。

$ sudo parted -a optimal /dev/sdb mklabel gpt
------------------------------
Information: You may need to update /etc/fstab.
------------------------------

$ sudo parted -a optimal -- /dev/sdb unit compact mkpart primary  ext3 "1" "-1"
------------------------------
Information: You may need to update /etc/fstab.
------------------------------

$ sudo mkfs.ext4 /dev/sdb1
------------------------------
mke2fs 1.42.9 (4-Feb-2014)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
2621440 inodes, 10485248 blocks
524262 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
320 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
4096000, 7962624

Allocating group tables:   0/320       done                            
Writing inode tables:   0/320       done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information:   0/320       done
------------------------------

6. /mnt/tmpに新ディスクをマウント

データコピーのため、新ディスクを/mnt/tmpにマウントする。

$ sudo mkdir /mnt/tmp
$ sudo mount /dev/sdb1 /mnt/tmp
$ df -h
------------------------------
Filesystem      Size  Used Avail Use% Mounted on
udev            2.0G  4.0K  2.0G   1% /dev
tmpfs           396M  692K  395M   1% /run
/dev/dm-0        15G   14G  981M  94% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
none            5.0M     0  5.0M   0% /run/lock
none            2.0G     0  2.0G   0% /run/shm
none            100M     0  100M   0% /run/user
/dev/sda1       236M   74M  150M  34% /boot
/dev/sdb1        40G   48M   38G   1% /mnt/tmp   ←★マウントされた
------------------------------

7. データコピー

Graylogのデータを旧ディスクから新ディスクにコピーする。データは以下ディレクトリに入っているすべてのファイルとなる。

$ ls -l /var/opt/graylog/data/
------------------------------
total 16
drwxr-x--- 3 graylog graylog 4096 Apr  1 11:59 elasticsearch
drwxr-x--- 3 graylog graylog 4096 May 12 21:40 etcd
drwxr-x--- 3 graylog graylog 4096 May 12 21:41 journal
drwxr-x--- 4 graylog graylog 4096 May 12 21:41 mongodb
------------------------------

cpコマンドでデータをコピーする。容量によっては時間がそこそこ必要となる。

$ sudo cp -ax /var/opt/graylog/data/* /mnt/tmp/

コピー完了後、diffでファイル差分の確認を行う。

$ sudo diff -qr --suppress-common-lines /var/opt/graylog/data  /mnt/tmp
------------------------------
Only in /mnt/tmp: lost+found   ←★この1行だけ表示されればOK
------------------------------

8. 元ディレクトリのデータを削除し、新ディレクトリと入れ替え

旧データを削除する。フォルダを間違えないように注意すること。

$ sudo rm -rf /var/opt/graylog/data/*

一時的にマウントしていた/mnt/tmpの新ディスクをアンマウントする。

$ sudo umount /mnt/tmp

アンマウントした新ディスクを/var/opt/graylog/dataにマウントする。

$ sudo mount /dev/sdb1 /var/opt/graylog/data

マウント結果を確認する。

$ df -h
------------------------------
Filesystem      Size  Used Avail Use% Mounted on
udev            2.0G  4.0K  2.0G   1% /dev
tmpfs           396M  692K  395M   1% /run
/dev/dm-0        15G  2.7G   12G  19% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
none            5.0M     0  5.0M   0% /run/lock
none            2.0G     0  2.0G   0% /run/shm
none            100M     0  100M   0% /run/user
/dev/sda1       236M   74M  150M  34% /boot
/dev/sdb1        40G   11G   27G  29% /var/opt/graylog/data
------------------------------

9. 起動時にマウントされるよう、fstabに追加

fstabに新ディスクが自動でマウントされるよう、1行設定を追加する。

$ echo '/dev/sdb1 /var/opt/graylog/data ext4 defaults 0 0' |  sudo tee -a /etc/fstab
/dev/sdb1 /var/opt/graylog/data ext4 defaults 0 0

fstabの中身を確認する。

$ cat /etc/fstab
------------------------------
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/graylog--vg-root /               ext4    errors=remount-ro 0       1
# /boot was on /dev/sda1 during installation
UUID=dc6ba91f-86f9-4218-bc13-ccba72b15e63 /boot           ext2    defaults        0       2
/dev/mapper/graylog--vg-swap_1 none            swap    sw              0       0
/dev/sdb1 /var/opt/graylog/data ext4 defaults 0 0
------------------------------

10. Graylogを再起動

最後にGraylogを再起動しておく。

$ sudo shutdown -r now

以上でディスク拡張作業は完了となるが、前述したとおり、Elasticsearchのエラーは解消しなかった。

解消するために、さらに対応する必要があったが、その方法は別記事にて記載することにする。

2017年5月13日土曜日

Linuxでプロキシ経由でインターネット通信をする (プロキシがある環境化でyumを使う)

ちょっとした小ネタ。

プロキシがある環境でyumを使ったら、なかなか成功しなかったので、備忘録として記載する。OSはCentOS 7.3となる。ちなみに、この手順はapt-getを使うLinuxディストリビューション(Ubuntuなど)でも同様に動作する。

環境変数を設定する

まずは失敗するパターン。

# yum check-update
------------------------------
読み込んだプラグイン:fastestmirror
Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=stock error was
14: curl#7 - "Failed to connect to 2001:4178:5:200::10: ネットワークに届きません"

~(以下略)~
------------------------------

「ネットワークに届きません」というエラーが出て失敗している。IPv6のアドレスが表示されているので、IPv4ではなくてIPv6のアドレスで接続しようとしているのかと疑ったが、そうではなくてプロキシ設定をしていないことが問題だった。

というわけで、以下のように環境変数を設定する。

# export http_proxy="http://<プロキシのIPアドレス>:<プロキシのポート>/"
# export https_proxy="http://<プロキシのIPアドレス>:<プロキシのポート>/"
# export ftp_proxy="http://<プロキシのIPアドレス>:<プロキシのポート>/"

# export ←確認コマンド
------------------------------
declare -x ftp_proxy="http://<プロキシのIPアドレス>:<プロキシのポート>/"
declare -x http_proxy="http://<プロキシのIPアドレス>:<プロキシのポート>/"
declare -x https_proxy="http://<プロキシのIPアドレス>:<プロキシのポート>/"
------------------------------

再度yumを実行すると、以下の通り成功した。

# yum check-update
------------------------------
読み込んだプラグイン:fastestmirror
Loading mirror speeds from cached hostfile
 * base: centos.usonyx.net
 * extras: download.nus.edu.sg
 * updates: centos.usonyx.net
base/7/x86_64/primary_db                                   | 5.6 MB   00:00  

NetworkManager.x86_64                     1:1.4.0-19.el7_3               updates
NetworkManager-libnm.x86_64               1:1.4.0-19.el7_3               updates

~(中略)~

wpa_supplicant.x86_64                     1:2.0-21.el7_3                 updates
xfsprogs.x86_64                           4.5.0-9.el7_3                  updates
------------------------------

2017年5月5日金曜日

MMCを使ってActive Directoryをリモート管理する

先日、ドメインコントローラーをServer Coreで構築した。Server Coreのドメインコントローラー作成の記事は以下。

------------------------------
・Windows Server 2008 R2 Server CoreでActive Directoryのドメインコントローラーを作った話① (Server Core OS初期設定)
https://tech-mmmm.blogspot.jp/2017/02/windows-server-2008-r2-server.html
・Windows Server 2008 R2 Server CoreでActive Directoryのドメインコントローラーを作った話② (ドメインコントローラー昇格)
https://tech-mmmm.blogspot.jp/2017/02/windows-server-2008-r2-server_25.html
------------------------------

Server CoreはGUIが利用できないので、ドメインのユーザー管理やグループポリシー設定を行う際にリモートから操作する必要がある。そこで、ドメインのメンバーサーバーからリモートでActive DirectoryとDNSを管理できるようにした。

MMC (Microsoft Management Console)を使って管理する

ドメインコントローラーやDNSは、通常MMC (Microsoft Management Console)を使って管理するが、ドメインコントローラーとなっていないメンバーサーバーでは、MMCに管理用のスナップインが表示されない。

そこで、サーバーマネージャーを開き、「役割と機能の追加」から、以下の下線の機能を追加する。

------------------------------
リモートサーバー管理ツール
 →役割管理ツール
  →AD DSおよびAD LDSツール
   →AD DSツール
    →AD DSスナップインおよびコマンドラインツール
  →DNSサーバーツール
------------------------------

 ※注:上記は既にインストール済みの画面となる

インストール後に「ファイル名を指定して実行」から「mmc」と入力するとMMCが起動できるので、「ファイル」→「スナップインの追加と削除」を選ぶとActive Directoryの管理用のスナップインが選択できる。主に管理として利用するスナップインは以下の通りとなる。個人的によく使うと思うものに★印を付けてみた。

------------------------------
・Active Directory サイトとサービス
・Active Directory スキーマ
・Active Directory ドメインと信頼関係
★Active Directory ユーザーとコンピューター
★DNS
★グループポリシーの管理
------------------------------


スナップインを追加した画面は以下の通り。MMC起動後の初回接続時は、多少時間が掛かることがあるが、Active Directoryのコンピューター情報やユーザー情報を確認できることがわかる。


Active Directoryは何もしなくてもドメインコントローラーに自動接続するが、DNSだけは接続先サーバーを選択する必要がある。


サーバーに接続できれば、以下のようにDNSも同じ画面で確認できるようになる。


以上で、Active DirectoryとDNSの管理がリモートからできるようになる。MMCの表示設定は保存できるので、名前を付けてファイルとして保存しておくと、今後利用する際に便利だろう。



2017年4月28日金曜日

vCenter Serverは不要。ESXi単独で仮想マシンのクローンを作る方法

vSphere環境で仮想マシンのクローンを作る場合は、vCenter Serverを用意する必要があると思っていたが、実はESXiシェルのコマンドを使えばESXi単独でクローンが作れてしまうことを最近知った。

若干手順が多くなるのでちょっと手間ではあるものの、無償のESXiのみの環境であってもクローンが使えることは非常に便利である。例えば、よく使うOSの仮想マシンはテンプレートとして1台作っておいて、今回記載する手順でクローンして使うようにすれば、検証作業のたびにOSインストールから始める必要がなくなって効率がよくなる。

ESXi単独での仮想マシンのクローンの手順

以下に手順を記載していく。

1. クローン先の仮想マシンの箱を作成

vSphere Clientなどでクローン元と同じ構成で仮想マシンを作成する。仮想マシン作成時に「標準」と「カスタム」が選べるが、「標準」を選んだ場合、必ず仮想マシンに1つディスクを作成する必要がある。このディスクは次の手順ですぐに消すため、1GBと小さくして作成しておけばよい。
※「カスタム」の場合は、ディスクを作らない仮想マシンの箱を作成できる。


2. クローン先の仮想マシンのディスク削除

仮想マシン作成時に作られたディスクは不要なので、仮想マシンから削除(ディスクからも削除)しておく。


3. sshでESXiシェルにログイン

Tera Termなどでログインする。なお、ESXiの場合は、「チャレンジレスポンス認証」を選んでログインする。

4. コピー元ディスクの確認

データストアは以下パスに存在する。

/vmfs/volumes/<データストア名>/<仮想マシン名>

クローン元のファイルを事前に確認しておく。コピー対象となるファイルは*.vmdkファイルとなる。以下確認例となる。

[root@t3011es60:~] ls -l /vmfs/volumes/ssd_local_01/t1162w28r/
total 7388176
------------------------------
-rw-------    1 root     root     42949672960 Apr 26 13:55 t1162w28r-flat.vmdk
-rw-------    1 root     root          8684 Apr 26 13:41 t1162w28r.nvram
-rw-------    1 root     root           524 Apr 26 13:55 t1162w28r.vmdk
-rw-r--r--    1 root     root            43 Apr 26 13:55 t1162w28r.vmsd
-rwxr-xr-x    1 root     root          2806 Apr 26 13:55 t1162w28r.vmx
-rw-------    1 root     root          4151 Apr 17 05:19 t1162w28r.vmxf
-rw-r--r--    1 root     root       1203822 Apr 18 21:24 vmware-1.log
-rw-r--r--    1 root     root        267260 Apr 26 13:41 vmware.log
------------------------------

5. ディスクコピーの実施

以下コマンドで仮想マシンのディスクをコピーする。

vmkfstools -i <クローン元> <クローン先> -d <ディスク形式>

"-d"オプションでディスクの形式を選択できる。

・zeroedthick (default) : シックプロビジョニング
・thin : シンプロビジョニング
・eagerzeroedthick : EagerZeroedThick (作成時に0書き込み)

以下シンプロビジョニング形式でクローンを作成する実行例となる。

[root@t3011es60:~] vmkfstools -i /vmfs/volumes/ssd_local_01/t1162w28r/t1162w28r.vmdk  /vmfs/volumes/iscsi_qnap_01/t1165w28r/t1165w28r.vmdk -d thin
------------------------------
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/ssd_local_01/t1162w28r/t1162w28r.vmdk'...
Clone: 100% done.
------------------------------

なお、仮想マシンがパワーオン状態の場合、以下のようにファイルがロックされているメッセージが表示されてしまいクローンが実行できない。

------------------------------
Failed to open '/vmfs/volumes/ssd_local_01/t1162w28r/t1162w28r-000001.vmdk': Failed to lock the file (16392).
Command exited with non-zero status 255
------------------------------

この場合は、一度仮想マシンのスナップショットを取得してから、再度vmkfstoolsコマンドを実行すれば成功する(スナップショットを取得すると、vmdkファイルのロックが差分用のvmdkファイルに移るため)。一時的にスナップショットを取得した場合は、作業後のスナップショット削除も忘れずに。

6. 仮想マシンにディスクを追加

vSphere Clientで、先ほどコピーしたvmdkファイルを指定して、仮想マシンのハードディスクを追加する。



7. 仮想マシンを起動

仮想マシンを起動する。特に問題なくログイン画面が表示される。


なお、仮想マシン起動状態でクローンを実施した場合は、以下のように正常にシャットダウンされなかった旨が表示されるが、「windows を通常起動する」を選べばOSは起動できる。


参考

ESX/ESXi ホスト端末を使用して個々の仮想マシン ディスクのクローンを作成する (2078416)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2078416

vmkfstools を使用した仮想マシン ディスクのクローン作成および変換 (2078921)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2078921

2017年4月22日土曜日

ESXi 6.0上にESXi 5.5の仮想マシンを作って、ESXi用のVMware Toolsをインストールした話 (ESXi on ESXi)

自宅の検証環境はESXi 6.0で構築しているが、ちょっとESXi 5.5の検証作業が必要になったので、仮想マシンとしてESXi 5.5を作成することにした。これは、Nested ESXiとかESXi on ESXiと呼ばれる方法で、検証等ではよく用いられる手法である。

本記事ではESXi 6.0上にESXi 5.5の仮想マシンを作成する方法と、ESXi 5.5用のVMware Toolsのインストール手順について記載する。

ESXiのインストール

まず、ESXi用に仮想マシンの箱を作成する。ESXi 6.0では、仮想マシンのOS選択にて、「その他」の中にESXiが選べるようになっているので、適切な種類を選択すればよい。今回は、ESXi 5.5なので、「VMware ESXi 5.x」を選択した。


また、ESXiにはインストール最小要件があるので注意する。以下KBに記載がある通り、ESXi 5.5の場合は、CPUは2コア以上、メモリは4GB以上必要となる。

・ESXi 5.5 のインストールおよびアップグレードのベスト プラクティス (2080534)
 https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2080534

作成した仮想マシンを起動する前に、vmxファイルを修正する必要がある。データストアブラウザにてvmxファイルをダウンロードし、最下行に以下2行を追加したのち、アップロードして上書きする。

------------------------------
vhv.enable = "TRUE"
hypervisor.cpuid.v0 = "FALSE"
------------------------------

作成した仮想マシンを起動させ、VMware社のサイトからダウンロードしたESXiのisoをマウントしてブートさせる。Nested ESXiであっても、インストール方法は特に変化がないため、ここでは詳細は割愛する。なお、ここで、CPUやメモリが最小要件を満たしていない場合、以下のようなエラーメッセージが表示され、インストールを進めることができないので注意。


ESXiの初期設定

正常にESXiのインストールが終わり、起動が完了したら、まずは仮想マシンのコンソールを用いて、管理用のIPアドレス設定をしておこう。


管理用ポートの設定ができれば、後はvSphere Clientにて接続して操作・設定が可能となる。ただし、ESXi 5.5にはvSphere Client 6.0では接続できないので、vSphere Client 5.5をインストールしておくことが必要となる。

なお、vSphere Clientは上書きインストールにはならず、各バージョンが共存して利用可能である(接続先のESXiやvCenter Serverのバージョンに応じて、適切なバージョンのvSphere Clientで接続がされる)ので、既に別バージョンのvSphere Clientがインストールされていたとしても、単純にvSphere Client 5.5のインストーラーを実行して、インストールしてしまえばよい。

ESXi用のVMware Toolsのインストール

以下URLからESXi用のVMware Toolsをダウンロードできる。

・VMWARE TOOLS FOR NESTED ESXI
 https://labs.vmware.com/flings/vmware-tools-for-nested-esxi#summary

なお、このVMware Toolsは、ESXi 6.0以降をネストする場合は不要のようだ。上記URLに「This Fling's functionality is now integrated into ESXi 6.0 and later. However, you can still download the Fling for ESXi 5.*」と記載されているとおり、ESXi 6.0以降では本機能(VMware Tools)は、もともと本体に組み込まれている模様。

ちなみに、ダウンロード場所が若干わかりづらいが、本文にさらりと記載されている、「This VIB package」のリンクをクリックすればよい。以下ファイル名のVIBファイルがダウロードされる。容量は2MB以下とコンパクト。

 esx-tools-for-esxi-9.7.2-0.0.5911061.i386.vib

ダウンロードしたVIBファイルは、vSphere Clientのデータストアブラウザを使って、アップロードしておく。今回は、ESXiのローカルディスクであるdatastore1にアップロードした。


VIBファイルをアップロードした後は、ESXiシェルにてインストールを実施する。親ESXiにて仮想コンソールを使うか、sshを有効にしている場合はsshにてESXiシェルにログインする。

ログインしたのち、以下コマンドを実行する。実行後、「The update completed successfully」と表示されれば成功。

# esxcli software vib install -v /vmfs/volumes/datastore1/esx-tools-for-esxi-9.7.2-0.0.5911061.i386.vib
------------------------------
Installation Result
   Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
   Reboot Required: true
   VIBs Installed: VMware_bootbank_esx-tools-for-esxi_9.7.2-0.0.5911061
   VIBs Removed:
   VIBs Skipped:
------------------------------

インストール結果に記載されている通り、ESXiの再起動が必要となるため、再起動をしておく。

# shutdown -r

後は親ESXiでVMware Toolsの実行状況を確認すればよい。「実行中 (サポート対象外)」という表示になっていればOK。IPアドレス情報が確認できるし、ゲストのシャットダウン等の機能も利用できるようになる。


以上で作業は完了となる。

2017年4月14日金曜日

ZabbixでCPUやメモリなどのリソース監視を行う

先日、ESXiのCPU、メモリの使用率をグラフに表示するという記事を書いた。その後しばらくして、ESXiのCPU使用率が高い値で張り付くという事象が発生した。


原因は、1台の仮想マシン(Windows Server)のSQL Serverが高負荷になったことであり、仮想マシンの再起動で復旧できた。しかし、根本原因は不明であり、不定期に再発することもあったことから、ZabbixでCPUのリソース監視を行うことにした。

アイテムを作る

ESXiのCPU使用率とメモリ使用率のアイテムの作り方は、別記事を参照。

トリガーを作る

「設定」→「テンプレート」→「Template Virt VMware Hypervisor」→「トリガー」を選択し、トリガーを新規作成する。

今回は例として、CPU周波数が2GHz = 2000000000Hzを600秒超過した場合に、「重度の障害」として検知する設定となる。余談だが、"2G"という表記でもZabbixは認識してくれるが、2G = 2*1024*1024*1024となり、正確な値にならないので注意が必要。

------------------------------
・名前:High CPU Usage
・条件式:{Template Virt VMware Hypervisor:vmware.hv.cpu.usage[{$URL},{HOST.HOST}].avg(600)}>2000000000
・深刻度:重度の障害
・障害イベントを継続して生成:チェックなし
・有効:チェックあり
------------------------------


なお、メモリを監視したい場合の条件式に入れる値は以下のようになる。
※事前にアイテムを作成していることが必要

------------------------------
・メモリ使用量
 vmware.hv.memory.used[{$URL},{HOST.HOST}]
・メモリバルーン
 vmware.hv.memory.size.ballooned[{$URL},{HOST.HOST}]
------------------------------

グラフで確認

グラフを作ってある場合は、グラフにもトリガー設定の閾値が表示されるので確認しておこう。今回設定した2GHzが監視閾値として、点線で表現されていることがわかる。


以上で設定は完了となる。