ログインできないec2インスタンスを調査する ｜ DevelopersIO
はじめに サーバを運用しているといろいろなことが起こります。 今回はなんらかのトラブルによりインスタンスが正常に起動しない、 ログインできなくなった場合の対応方法をご紹介します。 障害インスタンンスはAmazon LinuxでrootボリュームはEBSということで話を進めていきます。 障害インスタンスを停止する 正常に起動しない、ログインができないインスタンスをstopします。 サーバにログインできないのでマネジメントコンソールやAPIでstopします。 障害インスタンスのルートボリュームをデタッチする ルートボリュームのEBS IDを確認してVolumesへ移動します。 ・DescriptionのRoot Device 「/dev/xvda」をクリック また後でアタッチし直すのでRoot Device名はメモしておきます。 ・EBS ID をクリック ・Volumesに移動します。 ・A
【遂に来た！】EBS でボリュームサイズを変更できるようになりました（ボリュームタイプ変更も）
こんにちは、藤本です。 待ちに待ったアップデートです。EBS のボリュームサイズ、ボリュームタイプを変更できるようになりました。 Amazon EBS Update – New Elastic Volumes Change Everything 概要 今まで運用中に EBS のボリュームが足りなくなった場合、 一度スナップショットを作成して、 新規ボリューム作成して（この時にボリュームサイズ増加）、 ディスクを差し替える必要がありました。 これにより、インスタンスを停止する必要が発生したり、出来るだけダウンタイムを短くしたくてノーリブートでスナップショットを取ると整合性が担保されない、スナップショット取得から切り替えまでのデータの欠損が発生するなど、多くの問題がありました。 それが今回のアップデートにより、インスタンスの停止する必要がなく、データの欠損が発生することなく、ボリュームサイズを
AWSの失敗談 - しらなくてミスした話 - Qiita
お疲れ様です。 株式会社アカツキでサーバエンジニアとして働いている申です。 はじめに AWSを使用する上で失敗（ミス）した話と、それの原因及び対処方法などを共有し、みなさんは私と同じ過ちを起こさないようにすることが目的です。 Single-AZよりMulti-AZのほうが重い 概要 Single-AZとMulti-AZの両方性能テストする機会があり、Single-AZに比べてMulti-AZの方が性能が悪くていろいろ調べました。（特にコミット遅い） 原因 別AZ間でマスター・スレーブを配置するMulti-AZ構成では、AZ間で通信のレイテンシーが発生するためです。 Multi-AZのRDSにおいて、AZ間のデータレプリケーションは、非同期ではなく、 同期レプリケーション です。 よって、マスターDBに書き込み及びコミットが発生した場合、スレーブDBに書き込むための通信が発生し、それが完了す
Elastic EBS Volumes オペレーションを使用して Amazon ボリュームを変更する - Amazon EBS
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 Elastic EBS Volumes オペレーションを使用して Amazon ボリュームを変更する Amazon EBSElastic Volumes では、ボリュームサイズの増加、ボリュームタイプの変更、EBSボリュームのパフォーマンスの調整を行うことができます。インスタンスで Elastic Volumes をサポートしている場合は、ボリュームのデタッチやインスタンスの再起動を行うことなく、これらの操作を行うことができます。したがって、変更の適用中でも、アプリケーションを引き続き使用できます。 ボリュームの設定を変更するための料金は発生しません。ボリューム変更を開始すると、新しいボリューム設定料金が発生します。詳細については、「Amazon EBSの料金」ペー
EBSスナップショットからのレストア | DevelopersIO
渡辺です。 今年の11月の北海道は暖かく、スキー場に雪が降ってもレストア（雪解け）してしまいます（T_T 運用設計時、バックアップは検討しているにも関わらず、レストア手順の検討を行っていないケースは稀によくあります。 最悪、バックアップ（EBSのスナップショット取得）さえしておけば何とかなるといえばなんとかなるのですが、レストアが必要な場合に焦らないよう、レストア手順はしっかりと押さえておくべきでしょう。 今回は、EBSのスナップショットからのレストア方法について３パターン紹介します。 新規インスタンスを作成してのレストア ひとつ目の方法は、EBSスナップショットからAMIを作成し、そのAMIからEC2インスタンスを新規に作成する方法です。 AMIを作成する手間はありますが、元インスタンスを残したままにレストアできるため、レストア失敗時のリスクが最小に抑えられること、元インスタンスからのデ
AMIとEBS、スナップショットの関係がよくわかっていなかった話 - endokのブログ
AWSの話。 AWS使っている方であれば当たり前に理解している話かと思います。 AMIとEBS インスタンス起動時にAMIが読み込まれ、 EBSは追加データを保存する場所なのかなと思っていたのだけど、 どこからどこまでがEBSに保存されるんだ？などどいまいち腑に落ちていなかった。 で、ちゃんと調べてみたところ、 Amazon マシンイメージ（AMI）は、ソフトウェア構成（オペレーティングシステム、アプリケーションサーバー、アプリケーションなど）を記録したテンプレートです。AMI から、クラウドで仮想サーバーとして実行される AMI のコピーであるインスタンスを起動します。 (http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-instances-and-amis.html) AMI には次が含まれています。 インスタンス
EC2のスナップショットを自動的にAWS Lambdaで作成する - Qiita
AWS Lambda? サーバレスでプログラムを実行できるようなもの 1 か月 1,000,000 リクエストは無料 今回のような１日１回動かす程度なら無料でずっと使えます 詳しくは → https://aws.amazon.com/jp/lambda/faqs/ やりたいこと Lambdaのスケジュールイベントを使って自動的にEBSのスナップショットを作成する 今回使用する言語はPython スナップショットの対象は、EC2インスタンスのタグに「Backup-Generation」が付いているものとする Backup-Generationの値には、0以上の数字を指定する スナップショットの保存件数は、Backup-Generationの値とする 0のときはスナップショットを作成しない スナップショットの保存件数を超えた場合は、作成日付の古いものから削除する 作成したスナップショットのDe
growpartでRHEL EC2のルートパーティションを自動拡張する - サーバーワークスエンジニアブログ
こんにちは、サーバーワークス 技術1課の三井です。 EC2インスタンスの運用中に、ルートボリュームのEBSを拡張しなければならない場面、意外とあるんじゃないでしょうか。EBSの拡張方法についてGoogle先生に訪ねてみたところ、概ね以下のような手順が一般的なようでした。 対象EC2インスタンスにアタッチされているEBSボリュームのスナップショットを作成 1で作成したスナップショットを元に、大きいサイズのEBSボリュームを作成 対象EC2インスタンスから、既存EBSボリュームをデタッチ 2で作成したEBSボリュームを対象EC2インスタンスのルートボリュームとしてにアタッチ 上記の手順自体は問題ないですね。欲を言うとAWS側でEBSをよしなに拡張してくれる機能があったりするとますます我々のゆとり化に拍車が掛かるわけで最高なのですが、なかなかそうも行かないのでしょう。 さて、EBSの拡張には続き
[小ネタ] EC2インスタンスのEBSルートボリュームに自動でNameタグを付与する | DevelopersIO
ども、大瀧です。今回は小ネタを。 EBSはEC2インスタンスで使用するディスクボリュームのサービスで、インスタンス間で付け外ししたりインスタンスの削除時にボリュームを残すようにしたりといった、柔軟なボリューム管理が可能です。ただ、一旦インスタンスから外れてしまうと、どのボリュームを何に使っていたのかわからなくなってしまう恐れがあります。そうならないようボリュームにはNameタグとしてボリューム名を設定することができますが、EC2インスタンスのルートボリュームには既定でタグが付かないため、ついついボリューム名の設定を忘れてしまいがちです。 そこで今回は、インスタンス作成時に自動でルートボリュームにボリューム名を付与する方法をご紹介します。 仕組み インスタンス起動時に、ユーザーデータとして後述の処理を実行するよう設定します。 EC2インスタンス自身のインスタンス名とインスタンスIDを調査 ル
知らないあなたは損してる！M1を使ってる人は実はC3じゃなくてM3もおトクだったりする！ - yoshidashingo
cloudpackエバンジェリストの吉田です。 M3もmediumから揃ったことですし、今回はメモリ（RAM）の搭載量を軸に、Tokyo/Linux/オンデマンドの価格を並べてみたいと思います。例によってインスタンスストレージはメリデメ考えるうえでの基準にしてません。さて、何が見えるかな。 RAM：1.7GB タイプ.サイズvCPUCPU種別総ECURAMインスタンスストレージネットワークEBS最適化利用オンデマンド/Linux/Tokyo価格 m1.small 1 Intel Xeon ファミリー 1 1.7 1 x 160 低 -- $0.088 c1.medium 2 Intel Xeon ファミリー 5 1.7 1 x 350 中 -- $0.185 m1.smallを価格で置き換えるインスタンスはない c1.medium -> c3.large $0.007/h(↑) RAM：
AWS EC2インスタンスをPV形式からHVM形式に変換する（≒t1からt2に移行する） - Qiita
参考URL EC2のt1.microをt2.microへ移行する 手作業でPV -> HVMへの変換を行う方法 AWSで仮想化方式 PV(paravirtual) の既存 CentOS AMIを HVMにする 1の作業手順をベースに、少し改変を加えたもの シンボリックリンク追加のところが一番のミソ PV->HVM変換ツール pv2hvm.rbを試してみた ・Rubyスクリプトに変換作業を代行してもらう方法 ・2015-05現在では、sudo gem install aws-sdk --no-ri --no-rdocのところは、aws-sdkのv1を明示してインストールする必要があることに注意（参考：AWS SDK for Ruby V2） ・色々と問題が起きた（ルートデバイス名とブロックデバイス名を合わせないと動かない等）ため採用しなかった EC2編～PVインスタンスからHVMインスタンス
AWSにおける共有コンテンツ参照方式を検討する（"S3をマウントしたい"から始まった議論の一部始終） - Qiita
1.背景 S3の可用性や耐障害性って魅力的！ ただし、NFSマウントできないので、扱う側がS3のAPIで会話しないといけない。 現行では、複数台あるWebサーバがそれぞれファイルサーバへNFSマウントして共有コンテンツを参照していたんですが、S3だとこの構成がとれない。。。 なんとかならないか？そんな理由で始まった検討経緯を共有します。 2.方式案 思いついたのは、大きく以下の4方式。早速各方式について検討開始しました。 ①：S3コマンドで会話するよう、アプリケーション修正（AWS推奨） ②：何らかの形でS3のバケットをNFSマウントする（S3fsとか） ③：インスタンス側にデータを同期する（S3 syncとか） ④：EC2でファイルサーバを構築する（最終手段） 3.検討の流れ やはり最初は教科書通りにやろうとはしましたが、アプリケーション側の修正が大きいので非現実的でした。 ということで
Amazon RDS メモ | kirie.net blog
概要メモ MySQL5.1 普通に全機能使える RDS 用の API ツールで起動、終了 使用料金はEC2インスタンスよりも30%高い ストレージ料金はEBSと同じ ストレージのサイズは5GBから1TBまで 稼働させたままスケールアップ/スケールダウンができる（接続はちょっと切れるみたい） インスタンスクラスは自由に変更可能 ストレージ容量を増やす場合は使用中の容量より10%以上を指定する必要があるらしい ストレージ容量の指定は最低でも今と同容量なので減らすことはできない バックアップは自動 バックアップ領域はストレージサイズと同容量が無料 それ以上は追加料金 $0.15/GB スナップショットも作れる プレミアムサポートの対象 ついでにDBを使うときの選択指針みたいなものが書いてあった。 Amazon RDS アプリケーションやツールでRDBが必要な人。 MySQL を利用したいが、イン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
