【AWS】VPC環境の作成ノウハウをまとめた社内向け資料を公開してみる | DevelopersIO
よく訓練されたアップル信者、都元です。今回のお題は久しぶりにVPCです。 この記事は、アップデート版が存在します。最新情報は【AWS】VPC環境構築ノウハウ社内資料 2014年4月版を参照してください。 VPCを利用する理由 弊社で構築するAWSのサーバ環境は、一部の例外を除いて全てVPCを利用しています。 突然ですが、筆者はあまり大規模なシステムに携わった経験がありません。大規模なプロジェクトだと「数百数千台のサーバがラッキングされ、それが論理的なネットワークで区切られていて」「複数のデータセンターが冗長化された専用線で結ばれて」等、正直ちょっと想像つかない世界があるんだと思います。よくわかんないですが。 (c)John McStravick. (CC BY 2.0 Licensed) 逆に、小さなシステムであれば、月々数万円でレンタルサーバを借りて「1台のマシンの中にWebサーバとDB
cloudpackブログ - iptables, ntpd, postfix, openldap, phpldapadminをインストールした冗長化されたNATインスタンスを作る
iptables, ntpd, postfix, openldap, phpldapadminをインストールした冗長化されたNATインスタンスを作るメモ NATインスタンスに、iptables, ntpd, postfix, openldap, phpldapadminなど様々なソフトウェアをインストールし、 万能共通管理サーバと言えるようなものを構築する必要がありました。 今回は、その構築方法をこれまでのブログ記事を参照する形でまとめてみました。 ○High Availability NATの構築 NATインスタンスの構築は下記を参照下さい。 CloutInitでNATインスタンス(iptables)を構築 High Availability NAT化は下記を参照下さい。 High Availability NATの作成(CentOS6) ○ntpdの設定 ntpdの設定と参照EC2に対
NATインスタンスを冗長構成にしてみた - log4moto
Wizardによる標準構成のVPCにおいてNATインスタンスはSPOFであり、インスタンス障害や、単一AZの障害、AZ間接続障害によっても両AZのインターネット接続性が損なわれる可能性がある。そこで、NATインスタンスをAZ毎に用意し、障害発生時にfailoverする仕組みを考えてみた。 方針 なるべくAWSの１リージョン内で完結し、別リージョンや外部に監視用ホストなどをおかない 瞬間的にフェイルオーバーはおこなわず、毎分ごとにインターネット上のターゲットIPへの疎通を確認し、障害と思われる状態になったらフェイルオーバーを行う 疎通が回復したと思われた場合には、元の状態に戻す 構成 非常にわかりづらい図になっていますが、構成要素としては Subnet x 4 (Public, Private を AZ毎に１つずつ) NATインスタンス x 2 (AZ毎に１つずつ、当然ElasticIPも1
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
クックパッドでのVPC移行について
