Amazon S3から自動的に安価なAmazon Glacierへアーカイブする新機能が登場
Amazon S3に保存しているデータを、自動的に1GBあたり月額約1円というきわめて低価格な「Amazon Glacier」へアーカイブしてくれる。Amazonクラウドが発表したAmazon S3とAmazon Glacierが連係する新機能は、データアーカイブを非常に簡単に低コスト化できるソリューションとして使えるものです。 【AWS発表】Amazon S3がさらに便利に! データをAmazon Glacierに自動アーカイブできるオプションが追加! - Amazon Web Services ブログ Amazon Glacierの最大の魅力は、数百ギガバイトや数テラバイトにおよぶ大規模なデータをサポートするアーカイブサービスを、きわめて低価格で提供してくれている点です。ただしその利用には、Amazon S3とは別に用意されたAmazon Glacier用の操作をしなければならず、また
「EBSブートなAMIイメージで、インスタンスストレージを割り当てる」のついでにEBSブート時にルートデバイスとなるEBSの容量を増量する方法をメモしておきます。 *1 下記のようにインスタンスを立ち上げるとsda1のEBSデバイスの容量が100GBに増量されます。 $ ec2run ami-xxxxxxxx -b /dev/sda1=:100 -k user_key -g user_group このままだとシステムが増量された分を認識していません。 resize2fsを使ってファイルシステムのサイズを変更します。 $ df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 15481840 2212052 12483356 16% / none 874032 0 874032 0% /dev/shm $ resiz
Amazon EC2でEphemeral StoreをRAID0構成にしてディスクI/O性能を上げる | DevelopersIO
Ephemeral Storeは一時的なメモリドライブのようなもの Ephemeral Store(Instance Store)は、EBSブートのEC2インスタンス（Smallインスタンス以上）を立ち上げた際にオマケのように付いてくる領域です。インスタンスをTerminateすると一緒に消えてしまいます。とはいえ、インスタンスが起動中はずっと使うことができますので、ある程度高速に動作させたい場合には最適かもしれません。Management Consoleからは操作できないため、あまり知られていないかと思いますが、ドキュメントにはしっかり書いてあります。今回はこのEphemeral Storeを用いてRAID0構成を組みたいと思います。 Epemeral Storeを指定してインスタンスを起動する Epemeral Storeを使用するために起動オプションを付けます。今回はRAID0用に4
wikipediaのxmlデータのダウンロード後にmysqlに投入するも容量が足りなくなりAmazonのEBSを拡張したりと色々とやっていました。 本家のサイトはAmazonのEC2のサービスを利用しています。 EBSブートしたインスタンスの領域を拡張する場合、直接的に領域を拡張する場合はコマンドツールで起動オプションを変える必要があるそうです。 ただ蟻の管理人はFireFoxのElasticfoxというツールでEC2の管理をしているので、わざわざコマンドツールを導入するのが面倒だったので、一旦EBSのブート領域のスナップショットをとって、さらにとったスナップショットをボリュームにもどして（この時に領域を拡張）マウントし直す。という方法をとりました。 やり方は以下のとおりでした。 １．現在のインスタンスの停止（必ずstopで停止です。terminalだとインスタンスが消えてしまいます） ２
第4回では、Amazon EC2の仮想ストレージを対象にベンチマークテストを実施した。測定対象は、仮想マシンに付属する標準ストレージと、拡張用の仮想ストレージ「Elastic Block Store（EBS）」である。検証の結果、最上位仮想マシンの処理性能を引き出すには、EBSの利用が望ましいことが分かった。 測定に利用したのは、仮想クライアント群でファイルを読み書きするベンチマークソフト「dbench」。8種類の仮想マシンに対して、1から64まで段階的に仮想クライアントの数を増やしながらdbenchを実行した。測定対象のディレクトリを指定した以外のオプションはデフォルトのままで測定している 仮想クライアントが増えると性能が落ちる「標準ストレージ」 まず標準ストレージの結果を見てみよう（図1）。 最下位仕様のSmall仮想マシンを除けば、8または16仮想クライアントを境にスループットが落ち
Amazon EBS の特徴はマウントしたボリュームに対するスナップショットが取れることだろう。boto を使って簡単にバックアップ環境を以前に作業したメモを残しておく。boto は python のライブラリで、Amazon EC2 のインスタンス上から AWS の API を操作できる。boto の機能は多種であるが、今回は EBS の API を操作して、毎日1回スナップショットをとって5世代分保存する設定をしてみる。 botoのページ: http://code.google.com/p/boto/ 参考にしたURLhttp://2606-36j.blogspot.com/2009/03/amazon-ebs-snapshot.htmlhttp://emutyworks.com/?Amazon%20EC2%2FEBS%E3%81%AESnapshot%E3%82%92%E5%AE%9
EC2のインスタンスのバックアップは前回の通りS3にイメージ化して保存しておくのがいいと思うけど、/mnt以下のイメージ化の対象外ファイルをバックアップするにはEBSの方が便利です。 EC2とS3の関係はそんな密なものでもなく、EC2にS3を直接マウントすることができません。(擬似的には可能かも) しかもS3へのアクセスはhttp経由ということでrsyncも使えず速度が遅い。 そもそもEBSが何かというと外付け可能な永続的ブロックストレージです。わかりやすく言うとUSB接続の外付けハードディスクみたいなものです。 料金はインスタンスにマウントするしないに関わらず、EBSを借りた時点で1Gにつき一ヶ月当たり$0.1 + 100万リクエストにつき$0.1です。 一度マウントしてしまうと後はローカルドライブ同様に扱えます。 EBSの素晴らしいところは、一旦アンマウントして別のインスタンスにデータ
us-westのEC2環境を使い始めたのを機に、昨年末話題になっていたEC2インスタンスのEBSブートを試した。 その際、以下の各サイトを参考にさせて頂いた。 http://nxdxa.blogspot.com/2010/02/amazon-ebs-ec2.html http://blog.suz-lab.com/2010/01/migrating-centos-s3-based-ami-to-ebs.html http://coderslike.us/2009/12/07/amazon-ec2-boot-from-ebs-and-ami-conversion/ ネット上の情報を見るに、EC2インスタンスのEBSブートには、以下のようなメリットがあるようだ。 ・S3ベースのインスタンスと比較し、起動が速い。 ・インスタンス停止時に”terminate”ではなく”stop”を実行することで、
Amazon EBSは、永続的にデータを保持できるボリューム(ディスク)が扱える、Amazon EC2のストレージオプションです。 通常(instance-store)のAmazon EC2のサーバローカルに接続されているディスクは、良くも悪くも停止時(terminate)にデータが消えてしまいますが、Amazon EBSのストレージをルートパーティションとしてインスタンスを起動(EBSブート)した場合は、停止(stop)してもデータは保持されたままとなり、ディスクに対する信頼性は向上します。(instance-storeからのブートにも良い点はあります。それは別エントリで。) で、EBSブートのEC2インスタンスは、既存の(EBSブート用の)AMIから利用される方が多数だとは思いますが、このEBSブートした仮想サーバのルートパーティションのディスク容量は、デフォルトでは、AMIを作成した
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
