AWS日記 ITコンサルティング企業で働く男の

AWS（Amazon Web Services ）についての個人的な備忘録です。

EC2のスナップショットを最新何世代かだけ残して、あとは削除する、という運用をよく聞くけど、最新のスナップショットがあればEBSボリュームが復活出来るの？

どうなんだろ

   

※２０１４－８－２２追記

Amazon EBS ボリューム - Amazon Elastic Compute Cloud 

スナップショットの保存は差分ベースで行われるものの、最新のスナップショットさえあればボリュームを復元できるようにスナップショット削除プロセスは設計されています。

 だそうです。なるほど。。どういう仕組なんだろうか。。

 

suz-lab - blog: タグを利用したEC2のバックアップ(AMI取得)と世代管理

 ↑

関係無いけどこれすごい

 

EC2のエフェメラルディスク（インスタンスストア）をSwap領域として使用する

mkswapしてswaponで問題ないぽい。

その他今回知ったこと

  • エフェメラルディスクのサイズはインスタンスタイプ毎に固定
  • 外部ボリュームのDeleteOnTerminationは、デフォルトでOFFになってる
  • resize2fsは実行終了直後に反映されていた
  • fstabの最後の数字はDumpする・しない、起動時fsckする・しない　という意味

 

その他疑問に思ったことは以下のとおり。

 

現場からは以上です。

AMIMOTO.AMI（WordPressとかNginxとか最初から全部入っててキャッシュバリバリにチューニングされてるAMIで提供されてるやつ）は起動時にGitHubを見に行くのでプライベートセグメントからは起動しても無駄

ハマりました。。

 

■対策方法

セグメントをIGWに繋ぎ直して、EIP付与して外部に繋がるようにしてから

/opt/amimoto/bin/initial

見た感じこれで大丈夫ぽい。冪等性が担保されていることを信じましょう。。

CloudWatch単体では任意のEC2を起動することは出来ないが、AutoScalingGroupと連携すれば可能（なはず）

５分毎に死活監視をする、みたいな処理はEC2よりCloudWatchでやったほうがいいのはわかっていたが、その結果のアクションとしてメール送信や当該EC2のStop/Terminateくらいしか出来ないと勘違いしていた。

実際にはAutoScalingGroup経由で任意のAMIからEC2を起動することが出来るらしい。なのでそのAMIに仕込んでおけば色々と出来そう。

＃まだ検証中です。

 

この辺りを読むとだいたいわかる

 

 

 

ELBでSorryサーバへのフェールオーバーは現時点では手動で組むしかない

ELBのステータスをチェックしておいて、NGになったら自分自身をELBに登録する、というスクリプト。

自前でEC2立ててリバースプロキシ的にフェールオーバーさせるよりも、こっちのほうが良いでしょうね。

 

Amazon ELBでSorryサーバへのフェイルオーバーを実現する ｜ Developers.IO 

Route53を利用していない場合は、未だにヘルスチェック及びフェイルオーバーの機能は手組みする必要があります。無いなら作るしかないのです。