タグ別アーカイブ: S3

Amazon Web Services ブログ: 【AWS発表】Amazon S3 でバージョン管理されたオブジェクトもLifecycle管理が可能に

本日より、バージョン管理を有効にしたS3バケットに、Lifecycleルールを適用することができるようになりました。 この一見単純な変更により、S3、Glacierおよび、バージョン管理がより有益で便利なものになります。 例えば、最新バージョンのオブジェクトをS3に保持しつつ、古いバージョンはGlacierに移行するといったことをすることができます。 (必要とする可能性が最も高いだろう)最新バージョンはすぐに取得することができますし、古いバージョンも3〜5時間以内に確実にアクセスすることができます。 お客様のユースケースによりますが、最新のバージョンも含めて、全てのバージョンをGlacierに移行したいかもしれません。 オブジェクトを作成してから数日後に各バージョンを期限切れにしたいかもしれません。 この新機能を利用すれば、これらのユースケースに全て柔軟に対応することができます。 この新機能を使用することで、コストの安いGlacierのストレージと、S3のバージョン管理の柔軟性を組み合わせて、全体的なストレージコストの削減に貢献します。

引用元: Amazon Web Services ブログ: 【AWS発表】Amazon S3 でバージョン管理されたオブジェクトもLifecycle管理が可能に.

Amazon Web Services ブログ: 【AWS発表】Amazon S3 でバージョン管理されたオブジェクトもLifecycle管理が可能に

S3のLifecycle ManagementはS3とGlacierを統合し、各オブジェクトのStorage Classを介して、詳細を見ることができます。 Storage ClassがStandard か RRS (Reduced Redundancy Storage)のオブジェクトはS3に保存されています。 Storage ClassがGlacierの場合は、データがGlacierに保存されています。 Storage Classが何であるかに関わらず、オブジェクトはS3 APIおよび他のS3のツールを使ってアクセスすることができます。 Lifecycle Managementを使うと、Transition(Storage ClassをGlacierに変更)とExpiration(オブジェクトの削除)を引き起こす時間ベースのルールを定義することができます。 Expirationのルールを使うと、特定の世代より古くなったオブジェクトを削除することができます。 これらのルールを利用することで、お好みのロールバックウィンドウよりも古くなったオブジェクトを削除を自動的に削除し、ストレージコストを減らしつつ、それまではデータを利用可能にし続けることができます。

引用元: Amazon Web Services ブログ: 【AWS発表】Amazon S3 でバージョン管理されたオブジェクトもLifecycle管理が可能に.

fusionio vs huawei | ツチノコブログ

Huawei Tecal ES3000はMLCのNANDフラッシュ製品で

2.4TBでPCIe (2.0 x8)のインターフェースを持っています。

読み込み時の最大帯域は3.2GB/s書き込み時の最大帯域は2.8GB/sとなっています。

latencyでみると読み込みは8us、書き込みで49usの能力を持つ。

非常にユニークだなと思ったのがFPGAを3つ搭載しFTL、GC、RAIDやECCなどの処理を担うことでホストサーバのCPUをオフロードしてるところ。また、IOスケジューラーをダブルキューとすることで種類の違う命令を別々のキューで処理できるようになっている。この機能により性能の劣化を低減させ、iodrive2よりも2~3倍高速になっている。

価格も半値で設定されているようです。

日本法人は中国本体の開発部門と直接のパスを持っているようで対応が早くなるようです。

ドライバはカーネルそれぞれで専用のものを利用する必要がありますが結構そろっていました。

rhelやCentOS5/6のほとんどのカーネルには対応していると思われる。それ以外のカーネルで利用する場合はhuawei社でドライバをコンパイルしてもらう必要がある。

iodriveなんかは自分でカーネルに合わせてコンパイルしなおしますが、es3000では違う。

このあたりがちょっと怪しいような気もしています。ドライバのソースが出せないということで、どこかのパテントを侵害していたり怪しいコードが埋め込まれていたりしてたりして。んなことはないと思いますが。

引用元: fusionio vs huawei | ツチノコブログ.

雲になったコンピュータ: 老舗クラウドストレージサービスの倒産-Nirvanix-

②多機能が裏目に? ・・・ もうひとつの問題はSDNの多機能にあったようだ。基本のストレージ機能でAWS S3に挑戦しながら、一方で世界展開のマルチノードを用いて、CDN(Content Delivery Network)市場も狙っていた。ここには元祖Akamaiがいるし、挑戦者のLimeLightもいた。③本当の顧客は誰か? ・・・ このような多面作戦の結果、本当のユーザーが見えなくなった。初期のパワーユーザーとコンテンツデリバリーなどの企業ユーザーから、暫時、一般企業向けに同社方針が移っていったことからもそれは推察できる。④マネージメントは? ・・・ 以上のような状況はマネージメントの混乱を伺わせる。創業以来、NirvanixのCEOは5人。特に昨年からはひどかった。2010年以来のCEOが昨年12月にOracleに移籍、CSO(Chief Strategy Officer)が今年4月まで暫定CEOとなり、その後、MicrosoftとCiscoで役員だった現CEOが就任した。全ては戦略の問題だったように見える。最近の同社のキャッチフレーズは“Enterprise Cloud Storage Company”である。

引用元: 雲になったコンピュータ: 老舗クラウドストレージサービスの倒産-Nirvanix-.

【Windows Server 2012研究所】 Hyper-Vがさらに進化するWindows Server 2012 R2 -クラウド Watch

Windows Server 2012のHyper-Vでは、キーボード(i8042)、マウス、ビデオ(S3ビデオ)などのエミュレータが動作していた。しかしWindows Server 2012 R2のHyper-Vでは、これらのエミュレーション層をVMBus上で動作するリモートデスクトップに変更している。

リモートデスクトップを使用することで、キーボードやマウス、ビデオなどのエミュレーションが個々の仮想マシンごとに必要なくなった。システム全体でリモートデスクトップを利用することで、パフォーマンスが向上する。

引用元: 【Windows Server 2012研究所】 Hyper-Vがさらに進化するWindows Server 2012 R2 -クラウド Watch.

Advanced Configuration and Power Interface – Wikipedia

S0

通常の運用状態。

S1

スタンバイとよばれるメモリ、デバイス、レジスタコンテクストおよびキャッシュコンテクストをCPUが保持したまま割り込み等を止め、低消費電力状態に移行する状態である。タイマの復帰などを電源管理イベントとして扱い処理する程度で矛盾無く復帰可能である。

S2

デバイスなどのコンテクストが保存されているのはS1と同様であるが、キャッシュコンテクストがとレジスタコンテクストが失われているためS3と同様の方式で復帰する必要がある(ほとんど実装されている事例を見ない)。

S3

Suspend to RAMまたはスリープと呼ばれる状態で、メモリは保持されているが、チップセットの情報やレジスタコンテクストが失われる。サスペンドに入る前にOSはレジスタコンテクストをメモリに書き出し、16ビットコードの復帰ベクタをFACSの然るべき場所に書いておく。復帰はリセット状態から復帰し、BIOSがサスペンド状態であったことを検知して初期化を行った後復帰ベクタへ移行する。その後復帰ベクタからプロテクトモードへの復帰などを行って最終的にレジスタを書き戻して運用状態に復帰する。

S4

Suspend to Diskまたはハイバネーションと呼ばれる状態で、メモリ内容も失われる。メモリをディスクに書き出し、電源断状態にするのと同じである。初期は書き出し復帰はBIOSが行う事もあり、その場合の処理はS1やS3等と同等だったが、OSが行う場合は復帰時はブートローダやOSがハイバネーション内容が存在することを検出してメモリ内容を書き戻すことになる。

S5

完全なる電源断である。商用電源あるいは無停電電源装置から電力を全く消費しない状態。

引用元: Advanced Configuration and Power Interface – Wikipedia.

AWSにおける静的コンテンツ配信パターンカタログ(アンチパターン含む) | Developers.IO

アプリには api.example.com というホスト名が埋め込まれており、例えば http://api.example.com/image/foobar.png のようなURLで様々な画像にアクセスします。

アクセスが急増したとしても、CloudFrontがかぶさっていますので、高いパフォーマンスが発揮でき、オリジンに負荷を掛けることもありません。

配信体制を変更したい *1となった場合でも、Route53による独自ドメイン運用ですので、この指し先を変更することで、色々な配信体制に切り替えることが可能です。

可用性の面でも心配は無いでしょう。Route53のSLAは100%ですし、CloudFrontやS3についても、裏側が複数拠点分散体制になっていますので、AZが1つ丸ごとダウンしたとしても、サービスが継続できます。

コスト面でも、常時稼働のEC2インスタンスは必要ありませんので、非常に安く上がりますね。

引用元: AWSにおける静的コンテンツ配信パターンカタログ(アンチパターン含む) | Developers.IO.