Windows のグループポリシーでシャットダウンスクリプトが実行されない場合がある？
EC2 で動いている Windows Server の Windows Update 等の運用で OS 再起動前にサービスを落としたり必要なプロセスを落としたりすると思いますが、皆さんどうされてますか？
Windows のシャットダウンで自動で行われるサービス停止をアテにする人は少ないかもしれませんね。
よくあるのは、グループポリシーでシャットダウン時に明示的にスクリプトを実行するように設定することでしょうか。
↓こんな画面のやつです。
とある要件で、サービスを確実に停止してから OS をシャットダウンしたり再起動したりする、というのがありましてグループポリシーのシャットダウンスクリプトでいろいろテストしてみました。 思わぬ結果が出たので、共有しておこうと思います。
思わぬ結果？
ハードウェアに詳しい方なら当然の結果なのかもしれませんが、私はハードウェアに全く詳しくないので個人的には面白い結果になったと思っています。 グループポリシーのシャットダウンスクリプトですが、シャットダウンの定義というかどういう場面でトリガーされるのかが気になっていくつかパターンを試してみました。
問題なくシャットダウンスクリプトが実行される例
- OS 内から停止
- セッションマネージャから再起動
- RunCommand で WindowsUpdate
シャットダウンスクリプトが実行されない例
- AMI 作成時に再起動チェック
- コンソールから再起動/停止
どこからシャットダウン指示を出すかで動作が違う？
結果を見る限り、OS 内からシャットダウンを実行した場合はシャットダウンスクリプトが実行されて、OS 外（AWSコンソール等）からシャットダウンを実行した場合はシャットダウンスクリプトが実行されない、という動作をしているように見えますね。 セッションマネージャは ssm-user ユーザが OS 内から、RunCommand は SSM エージェントが OS 内部からコマンド送信しています。 一方、AMI 作成時の再起動オプションや、AWS コンソールからの再起動や停止は OS の外からシャットダウン命令を出しているのでそう思いました。
同じ言葉でも動作は厳密には違うっぽい
なんとなく AMI 作成時に再起動オプションをつけていて、サービスやプロセスの停止に長時間かかるような場合だとマズそうだなというのが見えてきました。 DB がないのであればほとんどの場合はそれでも大丈夫だと思いますが、一部のファイルの中身がなくなった！なんて例も 1 度だけですが経験しているので、確実にサービスやプロセスを止めてからバックアップを取りたい場合は、OS 内から当該サービス等を止めてから AMI 作成やスナップショット作成の API をコールするスクリプトを実行すると安心ですね。 もっといい方法があるような気がしますが、今時点では安心を買うにはこうするしかなさそうです。
そんなややこしいことしなくてももっと簡単もしくはシンプルにできるよ！って方がいれば教えていただけると嬉しいです！
VPC 内の EC2 インスタンスから AmazonProvidedDNS にクエリを投げるまでの道のり
毎日少しずつ DNS に詳しくなっていっている気がします、那須です。
EC2 インスタンスから DNS クエリを投げる宛先は DHCP options set に設定された DNS サーバになります。 ということはもうご存知でしょうか？ もしご存知ないなら↓こちらのドキュメントを読んでください。
タイトル通り、私は AmazonProvidedDNS にクエリを投げたかっただけなんですが、そこまでの道のりは長かったので忘れないように書いておきます。
何が大変だったの？
Windows Server がたくさん並ぶような案件だと、AD のドメインに参加していることが多いですよね？ 当然、DNS も AD DNS に向くわけです。 なので、↓こんなふうに DHCP options set の DNS サーバにオンプレ AD の IP アドレスを指定したんですね。
- domain-name = nantoka.com
- domain-name-servers = 1.2.3.4 (実際のものではありませんよ)
すると、DNS クエリは全部 1.2.3.4 に飛んでしまいます。 でも私は AmazonProvidedDNS に投げたい！ なぜかというと、VPC エンドポイントの名前解決をしたいから。
もちろん、↓このブログは読んでましたが、なんかもうちょっとシンプルで運用も楽な構成は取れないのか悩んでいました。
どう考えたか？
基本的な考えはこれです。
- このためだけに追加でサーバ運用したくない
- マルチ AZ 構成で AZ レベルの障害には備えたい
なので、DNS キャッシュサーバを立てる案は早々に消しました。
DNS のためだけにインスタンス運用するのめんどいので…
あと残った案は、
- Directory Service の Simple AD に転送して名前解決
- Route53 Resolver で名前解決
の 2 案で、どっちかにしようということになりました。
採用した構成
この構成で名前解決することに決めました。
理由は単純で、月額料金です。 今回は VPC エンドポイントの名前解決をしたいだけなので、構成も費用も小さくしたかったんですね。 比較すると、Simple AD 案は約 7000 円/月、Route53 Resolver 案は約 22000 円/月だったので、Simple AD 構成案にしました。 あと、WorkSpaces を使うならアクティブユーザが 1 ユーザいれば Simple AD の料金がタダになるらしいので、それも大きいですね。
Route53 Resolver を使うチャンスでもあったんですが Directory Service も使ったことなかったので、まずは古いほうから使ってみたかった、という個人的理由もあります。
オンプレ DNS で VPC エンドポイントの名前解決に悩んでいる方へ
名前解決の方法はたくさんあります。 今回は私が決めた内容とそれまでの考え方を書きましたが、新しいものを試したい方は Route53 Resolver を試せばいいし、Bind 等でいろいろ管理したいならキャッシュサーバ構成を取ればいいし、状況に応じて決めればいいと思います。 これがベストアンサーだ！ってのは無いと思いますので、いくつか実際に作ってみて試してみてください。 それが簡単にできるのがクラウドのいいところですよ！
