ついにきた！EFS（Elastic File System）が東京リージョンで利用可能になりました！ | DevelopersIO
こんにちは、菊池です。 ついにこの日がやってきました。AWS Summit Tokyo 2018でアナウンスされていた通り、EFS（Elastic File System）が東京リージョンで提供開始されました！ [速報] EFS（Elastic File System）が2018年7月に東京リージョンで提供開始！ #AWSSummit 最初のアナウンスから3年以上待ちましたが、ついに東京リージョンで堅牢でスケーラブルな、Multi-AZで利用できる共有ファイルシステムが利用可能になります。 EFSの使い方 改めてになりますが、EFSを使ってみます。利用方法は非常に簡単です。 マネジメントコンソールからサービスの画面を開きます。ちゃんと東京リージョンで使えるようになっていますよ！ VPCとサブネット、Security Groupを指定したら、 タグ、パフォーマンスオプション、暗号化有無を設定
オーロラは雲の上 — RDBのScalabilityとAvailability | DevelopersIO
Amazonは、なぜ、Aurora（オーロラ）という名前をつけたのだろう？ 僕は、どこかで見かけた、「それは、オーロラは雲（Cloud）の上にあるからさ」という一節が、とても気に入っている。 まさに、Auroraの最大の特徴は、Amazonのクラウド・サービスの上に構築されたデータベースであるというところにある。小論では、クラウド上（「雲の上」）のデータベースであるAuroraが、どのようにクラウドの機能を利用しているのかを、そのScalabilityとAvailabilityに焦点を合わせて紹介しようと思う。 AuroraのScalabilityとAvailability まず最初に、Auroraの主要なScalabilityとAvailabilityを確認しておこう。 Push-button Compute Scaling：コンソール画面で数クリックするだけで、CPU数・メモリーサイズ
nakanote blog UbuntuでDrobo風なNASを作る
前書き 前のエントリでは、FreeNASでDroboFS風なNASストレージを作りましたが、 Linuxのmd+LVMのほうがより柔軟で簡単に作れるので、Linuxでやり直しました。 繰り返しになりますが、目指すのはこんな条件のNASストレージです： 異なる容量のHDDを集約して、ひとつの仮想ディスクを作る 小容量HDDを大容量のものに挿し換えることで、データを保持したまま仮想ディスクの容量を増やせる 準備するもの HDD 3本以上: 異なる容量でOK。USB,PATA,SATAなどインターフェースが違っても大丈夫。 今回は80GB,160GB,500GBのディスクを準備しました。 PCサーバ：当然、準備したHDDがすべて挿せる構成である必要があります。 私は前エントリに引き続き、Proliant MicroServerを使用します。こいつは４本 ディスクをさすことができます。 Linux
HDDをSSDにしたらデータベースはどれだけ速くなるか？ オラクルと富士通が実験
リレーショナルデータベースを利用する際には、高い性能を引き出すために物理設計をし、スキーマを工夫し、パラメータのチューニングを行うことがつねに行われてきました。 性能のボトルネックはたいがいHDDにあり、いかにそのボトルネックを回避するかがチューニングのポイントですが、最近では性能向上のための武器として、HDDよりもずっとアクセス性能の高いSSDが注目されています。SSDはHDDと置き換えるだけで、アプリケーションにまったく手を加えずに性能向上を可能にする手段として非常に魅力的です。 HDDの代わりにSSDを利用したら、リレーショナルデータベースの性能はどれだけ向上するのでしょうか？ オラクルと富士通が共同検証を行い、その結果をホワイトペーパーとして先週発表しました（参考「日本オラクルと富士通 フラッシュ技術活用によるデータベース高速化を共同検証」）。 ホワイトペーパーでは、HDDの代わり
VMware ESXi と FreeNAS で仮想化環境を構築しよう - おともだちティータイム
概要 サーバを 2 台使って、 VMware ESXi と FreeNAS を構築します。 VMware ESXi が稼動してるサーバには HDD を一切接続せずに、 FreeNAS 上の NFS を VMware のストレージとして使用します。 なぜ 2 台使うのか ML115 は電源容量が 365W と非常に少なく*1、 CPU やメモリ、その他ハードウェアデバイスを接続した上で、大量の HDD を接続するとすぐに電源が足りなくなってしまいます。 また、 ML115 の電源は特殊な形状・ネジ配置になっており*2、通常の ATX 電源は使用できません*3。ですので、容量の大きい電源に交換するという方法以外で解決する必要がありました。 電力消費の大きい CPU と HDD を別々のマシンに分離することで解決するのが、今回の方法です。 また VMware ESXi では、ローカルに接続された
Not Only NoSQL!! 驚異的なまでにWRITE性能をスケールさせるSPIDERストレージエンジン
Webサービスでは、世界中からのトラフィックを捌く必要があるため、いくらチューニングしようとも一台のRDBMSでは捌ききることが出来ないのが常だ。MySQLは最初からマスター・スレーブ型のレプリケーション機能が搭載されており、スレーブをたくさんぶら下げることによって参照の負荷をスレーブに割り振るというスケールアウトによってその問題に対処してきた。スレーブによるスケールアウトは、参照（＝PV）が多いWebサイトと非常に相性が良く、幾多のWebサイトにおいて実績を作ってきているし、まだまだ利用されている。 しかしながら、サイトのトラフィックが劇的に増加してくるようになると、レプリケーションによる負荷分散では追いつかなくなってきた。そこで人々がとった選択肢は、memcachedを利用することである。memcachedはインメモリ型の高速なKVSであり、参照・更新性能はMySQLより格段に高い。M
サーバ仮想化環境でのお薦めストレージ構成 at nkjmkzk.net
A Place to discuss Oracle VM, Linux and Other Great Software.サーバ仮想化環境では「リソースプール」という概念を実現するために共有ストレージ構成が多く採用されます。しかし、そもそも現在のCPU性能とDISK I/O性能を鑑みれば、そもそもDISK I/O性能はCPU性能の進化に追いついておらず、共有ストレージ構成とすれば追い打ちをかけるようにそこがボトルネックとなります。多くの環境ではサーバ仮想化環境では「共有ストレージ型前提。しかしこれまでの何倍ものI/O性能が必要」という要件に対応するため、ミドル〜ハイエンドのストレージ装置を採用するという選択を行っています。その結果初期導入費用が高価なのはもちろんですが、そのあとも莫大な保守費を支払うことになります。そして拡張できるものの、拡張するためのパーツがまた高価、というスパイラルに陥
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://bearmini.net/blog/View.aspx?bid=1&aid=185
【イニシャルB】目からウロコの超快適パーソナルクラウド環境「Pogoplug」