SlideShare uma empresa Scribd logo
1 de 15
Baixar para ler offline
Copyright © 2015 AGREX INC. All rights reserved.
EC2 Auto Recovery
2015-06-04
札幌事業所 古山浩司
第15回 JAWS-UG札幌 勉強会
…で発表する予定だった
Copyright © 2015 AGREX INC. All rights reserved. 2
自己紹介
 AGREX 札幌事業所
・AWSグループ マネージャー
・2010年~AWSユーザー
・AWS Certified
Solution Architect (Associate)
SysOps Administrator (Associate)
 JAWS-UG 札幌支部 代表
 好きなAWSサービス : Workspaces
古山 浩司 (Hiroshi Koyama)
(AWS User Group Japan)
Copyright © 2015 AGREX INC. All rights reserved. 3
2012-1-12 AWS発表!
東京リージョン 3月~
Copyright © 2015 AGREX INC. All rights reserved.
従来のRecovery (≠Auto)
物理ホスト
仮想サーバー (EC2)
Stop
別の物理ホストに移動
→ Recovery完了
・Management Console
・CLI、API
Start
Copyright © 2015 AGREX INC. All rights reserved.
【補足】 "Stop & Start" と "Reboot"
Reboot
物理ホストは変わらない
Copyright © 2015 AGREX INC. All rights reserved. 6
"Auto" な Recovery ということは・・・
Stop & Start
これに相当することを
AWSが勝手にやってくれる…のか??
Copyright © 2015 AGREX INC. All rights reserved. 7
"耐障害性" の考え方が少し変わる??
用途次第では
シングル・サーバーで十分なケースも?
(おそらく)
数分待ち
ダウンタイム
なし
Copyright © 2015 AGREX INC. All rights reserved. 8
AWS documentation 曰く
(参考 http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
 CloudWatch の "システムステータスチェック" アラームがトリガー。
 リカバリ後も、Instance ID、Private IP、Elastic IP、インスタンスメタ
データ等、すべて元のインスタンスと同じ。
 インスタンスは再起動され、その際インスタンスは移行される。
 Auto Recovery が発動する要因
 ネットワーク接続の喪失
 システム電源の喪失
 物理ホストのソフトウェアの問題
 物理ホストのハードウェアの問題
Copyright © 2015 AGREX INC. All rights reserved. 9
システムステータスチェック
Copyright © 2015 AGREX INC. All rights reserved. 10
Auto Recovery を設定する
↑
正常値は0
Copyright © 2015 AGREX INC. All rights reserved. 11
設定完了
Copyright © 2015 AGREX INC. All rights reserved. 12
動作確認!
システムステータスチェック ⇒ "ALARM"
 ネットワーク接続の喪失
 システム電源の喪失
 物理ホストのソフトウェアの問題
 物理ホストのハードウェアの問題
唯一、
これならできそう
Copyright © 2015 AGREX INC. All rights reserved. 13
システムステータスはOKのまま!!!
(インスタンスステータスはALARM)
ネットワークをダウン!
$ ifconfig eth0 down
ちなみに… " ifdown eth0 " もダメ。
Copyright © 2015 AGREX INC. All rights reserved. 14
結局のところ・・・
 100台を1年くらい動かせば、運が良ければ見れる…かも?
Auto Recovery、設定はできても試せず。。
「トリガー条件="INSUFFICIENT DATA (不足)" + インスタンスを "STOP"」
これで Recovery アクションが走ることは確認できました・・・が、
STOPはSTOPのまま、⇒ 意味なし。。
 意図的に Auto Recovery させる方法、誰か知っていたら
是非教えてください。
 「手動 Auto Recovery??」機能の追加に期待!
THANK YOU

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

ネットワークと絡めてこそ真価を発揮!AWS Outpostsの基本と概要
ネットワークと絡めてこそ真価を発揮!AWS Outpostsの基本と概要ネットワークと絡めてこそ真価を発揮!AWS Outpostsの基本と概要
ネットワークと絡めてこそ真価を発揮!AWS Outpostsの基本と概要
 
Best Practices for Running PostgreSQL on AWS
Best Practices for Running PostgreSQL on AWSBest Practices for Running PostgreSQL on AWS
Best Practices for Running PostgreSQL on AWS
 
クラウドインテグレーターのお仕事
クラウドインテグレーターのお仕事クラウドインテグレーターのお仕事
クラウドインテグレーターのお仕事
 
reGrowth福島 サーバレスの事例とセキュリティサービス
reGrowth福島 サーバレスの事例とセキュリティサービスreGrowth福島 サーバレスの事例とセキュリティサービス
reGrowth福島 サーバレスの事例とセキュリティサービス
 
20170809 AWS code series
20170809 AWS code series20170809 AWS code series
20170809 AWS code series
 
[JAWS DAYS 2019 /Open Mic]AWSの運用最適化のためにNHN テコラスが提案していること
[JAWS DAYS 2019 /Open Mic]AWSの運用最適化のためにNHN テコラスが提案していること[JAWS DAYS 2019 /Open Mic]AWSの運用最適化のためにNHN テコラスが提案していること
[JAWS DAYS 2019 /Open Mic]AWSの運用最適化のためにNHN テコラスが提案していること
 
JAWS DAYS 2016 Mafia Talk
JAWS DAYS 2016 Mafia TalkJAWS DAYS 2016 Mafia Talk
JAWS DAYS 2016 Mafia Talk
 
AWSの運用自動化サービス Cloud Automator で攻めのシステム運用 amimoto スタック編
AWSの運用自動化サービス Cloud Automator で攻めのシステム運用 amimoto スタック編AWSの運用自動化サービス Cloud Automator で攻めのシステム運用 amimoto スタック編
AWSの運用自動化サービス Cloud Automator で攻めのシステム運用 amimoto スタック編
 
エイチ・アイ・エス AWS導入状況 FY2015 - AWS Summit Tokyo 2015 Day 1 : EG-05
エイチ・アイ・エス AWS導入状況 FY2015 - AWS Summit Tokyo 2015 Day 1 : EG-05エイチ・アイ・エス AWS導入状況 FY2015 - AWS Summit Tokyo 2015 Day 1 : EG-05
エイチ・アイ・エス AWS導入状況 FY2015 - AWS Summit Tokyo 2015 Day 1 : EG-05
 
BeeX2020 リモートワーク推進キャンペーン
BeeX2020 リモートワーク推進キャンペーンBeeX2020 リモートワーク推進キャンペーン
BeeX2020 リモートワーク推進キャンペーン
 
2018/7/27 SAP on AWS お客様事例セミナー@大阪(BeeX資料2/2)
2018/7/27  SAP on AWS お客様事例セミナー@大阪(BeeX資料2/2)2018/7/27  SAP on AWS お客様事例セミナー@大阪(BeeX資料2/2)
2018/7/27 SAP on AWS お客様事例セミナー@大阪(BeeX資料2/2)
 
Amazon Connectで到着報告を自動化
Amazon Connectで到着報告を自動化Amazon Connectで到着報告を自動化
Amazon Connectで到着報告を自動化
 
Serverless Meetup Tokyo #2 オープニング
Serverless Meetup Tokyo #2 オープニングServerless Meetup Tokyo #2 オープニング
Serverless Meetup Tokyo #2 オープニング
 
My Individual Output
My Individual OutputMy Individual Output
My Individual Output
 
AWSで稼働している ブログ(ヤマムギ+3)の コスト
AWSで稼働している ブログ(ヤマムギ+3)の コストAWSで稼働している ブログ(ヤマムギ+3)の コスト
AWSで稼働している ブログ(ヤマムギ+3)の コスト
 
AWSとは、AWS構築事例紹介
AWSとは、AWS構築事例紹介AWSとは、AWS構築事例紹介
AWSとは、AWS構築事例紹介
 
AWSセキュリティ新機能と共に進化した My Individual blog (私の個人ブログ) since 2014
AWSセキュリティ新機能と共に進化した My Individual blog (私の個人ブログ)  since 2014AWSセキュリティ新機能と共に進化した My Individual blog (私の個人ブログ)  since 2014
AWSセキュリティ新機能と共に進化した My Individual blog (私の個人ブログ) since 2014
 
AWS設計ガイドラインで取り組むクラウドシフト
AWS設計ガイドラインで取り組むクラウドシフトAWS設計ガイドラインで取り組むクラウドシフト
AWS設計ガイドラインで取り組むクラウドシフト
 
2018/9/11 SAP on AWS お客様事例セミナー@東京(BeeX資料2/2)
2018/9/11 SAP on AWS お客様事例セミナー@東京(BeeX資料2/2)2018/9/11 SAP on AWS お客様事例セミナー@東京(BeeX資料2/2)
2018/9/11 SAP on AWS お客様事例セミナー@東京(BeeX資料2/2)
 
re:Growth 2021 コンピュートサービスの進化を語る
re:Growth 2021 コンピュートサービスの進化を語るre:Growth 2021 コンピュートサービスの進化を語る
re:Growth 2021 コンピュートサービスの進化を語る
 

Semelhante a EC2 Auto Recovery (第15回JAWS-UG札幌勉強会)

[A31]AWS上でOracleを利用するためのはじめの一歩!by Masatoshi Yoshida
[A31]AWS上でOracleを利用するためのはじめの一歩!by Masatoshi Yoshida[A31]AWS上でOracleを利用するためのはじめの一歩!by Masatoshi Yoshida
[A31]AWS上でOracleを利用するためのはじめの一歩!by Masatoshi Yoshida
Insight Technology, Inc.
 

Semelhante a EC2 Auto Recovery (第15回JAWS-UG札幌勉強会) (20)

AWS Lambda にまつわるおいしい話
AWS Lambda にまつわるおいしい話AWS Lambda にまつわるおいしい話
AWS Lambda にまつわるおいしい話
 
Windowsシステムの AWS移行とMulti-AZ化 - JAWS DAYS 2015
WindowsシステムのAWS移行とMulti-AZ化 - JAWS DAYS 2015 WindowsシステムのAWS移行とMulti-AZ化 - JAWS DAYS 2015
Windowsシステムの AWS移行とMulti-AZ化 - JAWS DAYS 2015
 
[沖縄]はじめての運用自動化 Cloud automatorを触ってみよう!
[沖縄]はじめての運用自動化 Cloud automatorを触ってみよう![沖縄]はじめての運用自動化 Cloud automatorを触ってみよう!
[沖縄]はじめての運用自動化 Cloud automatorを触ってみよう!
 
エンジニア向け初めてのAWS (2015年1月6日)
エンジニア向け初めてのAWS (2015年1月6日)エンジニア向け初めてのAWS (2015年1月6日)
エンジニア向け初めてのAWS (2015年1月6日)
 
AWS re:invent振り返りServerlessでサーバコスト以外もいろいろ削減
AWS re:invent振り返りServerlessでサーバコスト以外もいろいろ削減AWS re:invent振り返りServerlessでサーバコスト以外もいろいろ削減
AWS re:invent振り返りServerlessでサーバコスト以外もいろいろ削減
 
DevOps on azure 高品質クラウドデザインを求めて
DevOps on azure 高品質クラウドデザインを求めてDevOps on azure 高品質クラウドデザインを求めて
DevOps on azure 高品質クラウドデザインを求めて
 
20150613 Azure最新Update
20150613 Azure最新Update20150613 Azure最新Update
20150613 Azure最新Update
 
オレ流クラウドデザイン
オレ流クラウドデザインオレ流クラウドデザイン
オレ流クラウドデザイン
 
Anchors Aweigh!! - re:Invent報告@re:Port 2016 大阪
Anchors Aweigh!! - re:Invent報告@re:Port 2016 大阪Anchors Aweigh!! - re:Invent報告@re:Port 2016 大阪
Anchors Aweigh!! - re:Invent報告@re:Port 2016 大阪
 
[A31]AWS上でOracleを利用するためのはじめの一歩!by Masatoshi Yoshida
[A31]AWS上でOracleを利用するためのはじめの一歩!by Masatoshi Yoshida[A31]AWS上でOracleを利用するためのはじめの一歩!by Masatoshi Yoshida
[A31]AWS上でOracleを利用するためのはじめの一歩!by Masatoshi Yoshida
 
ユーザーからみたre:Inventのこれまでと今後
ユーザーからみたre:Inventのこれまでと今後ユーザーからみたre:Inventのこれまでと今後
ユーザーからみたre:Inventのこれまでと今後
 
Azuredevopsakskeda
AzuredevopsakskedaAzuredevopsakskeda
Azuredevopsakskeda
 
Aws導入時にまず考える〇〇のこと
Aws導入時にまず考える〇〇のことAws導入時にまず考える〇〇のこと
Aws導入時にまず考える〇〇のこと
 
AWS App RunnerでASP.NET Core Webアプリケーションを動かしてみた
AWS App RunnerでASP.NET Core Webアプリケーションを動かしてみたAWS App RunnerでASP.NET Core Webアプリケーションを動かしてみた
AWS App RunnerでASP.NET Core Webアプリケーションを動かしてみた
 
20151030 オープンデータとセキュリティon aws
20151030 オープンデータとセキュリティon aws20151030 オープンデータとセキュリティon aws
20151030 オープンデータとセキュリティon aws
 
AWS Serverless++
AWS Serverless++AWS Serverless++
AWS Serverless++
 
20180613 AWS Black Belt Online Seminar AWS Cloud9 入門
20180613 AWS Black Belt Online Seminar AWS Cloud9 入門20180613 AWS Black Belt Online Seminar AWS Cloud9 入門
20180613 AWS Black Belt Online Seminar AWS Cloud9 入門
 
AWSで画像認識をやってみる~DL3分クッキング~
AWSで画像認識をやってみる~DL3分クッキング~AWSで画像認識をやってみる~DL3分クッキング~
AWSで画像認識をやってみる~DL3分クッキング~
 
AWS運用自動化への第一歩 
AWS運用自動化への第一歩 AWS運用自動化への第一歩 
AWS運用自動化への第一歩 
 
(AWS DevOps祭り 2018) AWS Management Toolsサービスアプデートのご紹介
(AWS DevOps祭り 2018) AWS Management Toolsサービスアプデートのご紹介(AWS DevOps祭り 2018) AWS Management Toolsサービスアプデートのご紹介
(AWS DevOps祭り 2018) AWS Management Toolsサービスアプデートのご紹介
 

EC2 Auto Recovery (第15回JAWS-UG札幌勉強会)

  • 1. Copyright © 2015 AGREX INC. All rights reserved. EC2 Auto Recovery 2015-06-04 札幌事業所 古山浩司 第15回 JAWS-UG札幌 勉強会 …で発表する予定だった
  • 2. Copyright © 2015 AGREX INC. All rights reserved. 2 自己紹介  AGREX 札幌事業所 ・AWSグループ マネージャー ・2010年~AWSユーザー ・AWS Certified Solution Architect (Associate) SysOps Administrator (Associate)  JAWS-UG 札幌支部 代表  好きなAWSサービス : Workspaces 古山 浩司 (Hiroshi Koyama) (AWS User Group Japan)
  • 3. Copyright © 2015 AGREX INC. All rights reserved. 3 2012-1-12 AWS発表! 東京リージョン 3月~
  • 4. Copyright © 2015 AGREX INC. All rights reserved. 従来のRecovery (≠Auto) 物理ホスト 仮想サーバー (EC2) Stop 別の物理ホストに移動 → Recovery完了 ・Management Console ・CLI、API Start
  • 5. Copyright © 2015 AGREX INC. All rights reserved. 【補足】 "Stop & Start" と "Reboot" Reboot 物理ホストは変わらない
  • 6. Copyright © 2015 AGREX INC. All rights reserved. 6 "Auto" な Recovery ということは・・・ Stop & Start これに相当することを AWSが勝手にやってくれる…のか??
  • 7. Copyright © 2015 AGREX INC. All rights reserved. 7 "耐障害性" の考え方が少し変わる?? 用途次第では シングル・サーバーで十分なケースも? (おそらく) 数分待ち ダウンタイム なし
  • 8. Copyright © 2015 AGREX INC. All rights reserved. 8 AWS documentation 曰く (参考 http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-instance-recover.html)  CloudWatch の "システムステータスチェック" アラームがトリガー。  リカバリ後も、Instance ID、Private IP、Elastic IP、インスタンスメタ データ等、すべて元のインスタンスと同じ。  インスタンスは再起動され、その際インスタンスは移行される。  Auto Recovery が発動する要因  ネットワーク接続の喪失  システム電源の喪失  物理ホストのソフトウェアの問題  物理ホストのハードウェアの問題
  • 9. Copyright © 2015 AGREX INC. All rights reserved. 9 システムステータスチェック
  • 10. Copyright © 2015 AGREX INC. All rights reserved. 10 Auto Recovery を設定する ↑ 正常値は0
  • 11. Copyright © 2015 AGREX INC. All rights reserved. 11 設定完了
  • 12. Copyright © 2015 AGREX INC. All rights reserved. 12 動作確認! システムステータスチェック ⇒ "ALARM"  ネットワーク接続の喪失  システム電源の喪失  物理ホストのソフトウェアの問題  物理ホストのハードウェアの問題 唯一、 これならできそう
  • 13. Copyright © 2015 AGREX INC. All rights reserved. 13 システムステータスはOKのまま!!! (インスタンスステータスはALARM) ネットワークをダウン! $ ifconfig eth0 down ちなみに… " ifdown eth0 " もダメ。
  • 14. Copyright © 2015 AGREX INC. All rights reserved. 14 結局のところ・・・  100台を1年くらい動かせば、運が良ければ見れる…かも? Auto Recovery、設定はできても試せず。。 「トリガー条件="INSUFFICIENT DATA (不足)" + インスタンスを "STOP"」 これで Recovery アクションが走ることは確認できました・・・が、 STOPはSTOPのまま、⇒ 意味なし。。  意図的に Auto Recovery させる方法、誰か知っていたら 是非教えてください。  「手動 Auto Recovery??」機能の追加に期待!