ELB経由でフォワードプロキシ on Amazon EC2 | iret.media
こんにちは、cloudpack の 三浦剛慈 です。 ■実現したい事 AWS上でフォワードプロキシサーバを冗長構成(act/act)で用意する。インタネット越しでそのプロキシサーバを利用する。 ■実現方法 Internet facingのELBを作成する Cent OS on EC2上でフォワードプロキシサーバーを2台起動させる ELBにフォワードプロキシサーバーを2台ぶら下げる ■構成イメージ ■構築方法 ※NATの構築方法については割愛します。 1.フォワードproxyサーバ ※今回はApacheを利用 1-1.apacheのインストール #yum install httpd 1-2.サービスポートを80以外に変更する ※ここがキモ（80だとELB経由では実現できません！） Listen 8080 1-3.フォワードproxyを有効に設定する ProxyRequests On Orde
kelbimで管理するAWS, ELB | iret.media
AWSのELBの設定をRubyのDSLで管理できるCLIツール。 作成者サイト http://so-wh.at/entry/20131105/p1 Github https://github.com/winebarrel/kelbim 手順 インストール インストール ➜ gem install kelbim --no-ri --no-rdoc 確認 ➜ kelbim -v kelbim 0.2.6 ➜ kelbim kelbim Usage: kelbim [options] -p, --profile PROFILE_NAME -k, --access-key ACCESS_KEY -s, --secret-key SECRET_KEY -r, --region REGION -a, --apply -f, --file FILE -n, --elb-names NAMES --dry
ELB 配下の Apache で特定の User Agent をログに記録しないようにする | iret.media
よく忘れるのでメモっておきますのかっぱ(@inokara) です。 ELB のヘルスチェックログを記録しないようにする 以下、参考です。 Apache &bt; HTTP サーバ &bt; ドキュメンテーション &bt; バージョン 2.4 ということで ELB のヘルスチェックのログは下記のようなログになります。 xxx.xxx.xxx.xxx – – [18/Aug/2014:01:46:50 +0000] “GET /index.html HTTP/1.1” 200 521 “-” “ELB-HealthChecker/1.0” – “-“ ということで、バックエンドの Apache 側では以下のように SetEnvIf を利用して、ログに記録しないユーザーエージェントを定義します。 SetEnvIf User-Agent “ELB-HealthChecker.*” nolog Cu
ELBアクセスログを期限付きでS3に自動保存する設定 | iret.media
cloudpack の 三浦 剛慈です。 ELBアクセスログを期限付きでS3に自動保存する設定 ・ELBのログ保存機能 ・S3のlifecycle設定 を利用して、2つのELBに対するアクセスログを、同一バケットの別フォルダに期限付きで保存するよう設定します。 今回の例では ＜ELB＞ 1.elb01 2.elb02 の二つのELBを利用し、 ＜S3＞ koujibacketバケットのelbフォルダ下にelb01とelb02のアクセスログを期限付きで保存します。 参考URL: http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/configure-s3-bucket.html http://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-
Elastic Load Balancerを使用したEC2にIPでHTTPアクセス拒否する方法について | iret.media
: ServerName dummy ServerSignature Off Order deny,allow Deny from All : 〆Health Check設定 Ping Protocol：HTTP Ping Port：80 Ping Path：/index.html http://example.com/index.html 動作不具合内容 ELBのHealthCheckでhttp://example.com/index.html の監視を行うと、 “OutofService”となってしまう。 原因 ELBからEC2にはIPでアクセスしDVHにアクセスが向いてしまう為、拒否(403 Forbidden)されてしまう。 対処方法 その① ELB healthcheckをTCP 80の監視設定に変更する Ping Protocol：TCP Ping Port：80 デメリット：
OpenVPN serverをインストールしたEC2を利用してinternal ELBで内部Webサイトを閲覧する | iret.media
cloudpack の がみさんです。 cloudpackブログ: VPCのプライベートなサブネットにOpenVPNでVPN接続を参考にしながら 各種VPNクライアント -> OpenVPN(NAT) -> internal ELB -> Web Serversも作れるようねと思ってやってみたけど、OpenVPNサーバとVPN張ってからcurl -vでチェックしていて、行きはconnectedになったけど戻りが無い現象に詰まっていたのでメモを残します NATインスタンスを作る上での初歩的なことを読み飛ばしてた・・・恥ずかしい。 忘れないこと OpenVPN Server(NAT)を作った時はクライアントへの戻りパケットを受け付けるのでSource/Dest CheckはDisableにする OpenVPNで割り当てるアドレス帯のパケットを戻せるようにRoute TableへDestinat
ELBってなんじゃ？（アクセスログがやってきた） | iret.media
ここで、「Enable Access Logs」にチェックを入れ、 Interval：ログ出力間隔（現状５分か60分） S3 Location：ログ出力先のS3ロケーション（Create the location for meをチェックすると自動でつくられる） を入力し、「Save」をクリックします。 しばらくすると、指定したS3のロケーションに、ログが出力されます。 中身をみてみると、以下のようになっています。 2014-03-06T23:50:37.819662Z manage 54.248.248.218:60123 10.156.231.23:80 0.00008 0.002195 0.000074 403 403 0 5039 "GET https://mng.cloudpack.jp:443/ HTTP/1.1" 2014-03-06T23:54:42.332009Z memo
cloudpackブログ - VPC環境で作れるELBの上限について調べてみました
公式ドキュメントに下記のような記述があります。 ロードバランサーが正しくスケーリングを行えるように、ロードバランサーをアタッチするサブネットの CIDR ブロックを、最低でも /27 ビットマスク（例: 10.0.0.0/27）に指定してください。 ロードバランサーをアタッチするサブネット内には自由な IP アドレスが 20 個以上含まれている必要があります。 Amazon VPC での Elastic Load Balancing のデプロイ 上記をもとに/27のサブネットでは、実際いくつまでELBを作る事ができるか調査してみました。 10.0.1.0/27でサブネットを作成したところ、初期の利用可能なIPアドレス数は27でした。 ELBを順に作成してみたところ、8個までは問題なく作ることができました。 しかし、9個目で下記のようなエラーメッセージが表示されました。 Error: Inv
cloudpackブログ - Deep Security ManageにELB経由でアクセス
過去記事「 Deep Security Manager 9.0のデータベースをRDS(Oracle)にしてみた 」にてデータベース側の冗長化が できました。 次はDeep Security Managerを冗長化(Multi-Node)したいと思うのですが、現在Deep Security Managerの ノード追加に難航しています。 そこで、先にELBでの分散を試してみました。 ELBは下記のように作成しています。 Deep Security Manager側でELBの情報を入力する必要もあります。 System Settings > Advanced これでELB経由でも管理画面にアクセスできるようになります。 尚、上記の画面から管理画面だけでなくAgentとHeartbeat通信したり、Relayサーバに接続するポートも ロードバランサー経由にすることができそうです。 (その場合はI
cloudpackブログ - HAProxyをDNS名で指定したバックエンドのIPアドレスが変わったらリロードする
以前、(ELBとからめて)Hostヘッダでの振り分けをHAProxyでやってみるのような記事を紹介しました。 しかし、下記のような指摘をいただきました。 HAProxyは起動時に名前解決してIPをキャッシュするので、ELBのIP変更を検知・リロードする仕組みが必要ですね @suz_lab – blog: (ELBとからめて)Hostヘッダでの振り分けをHAProxyでやって… htn.to/72F8JM — Michael H. Oshitaさん (@ijin) 12月 10, 2012 よく考えるとご指摘の通りで、HAProxyはバックエンドサーバをDNS名で指定すると、最初に名前解決した IPアドレスをキャッシュし、そのまま使ってしまいます。 そして、ELBは(internalも)IPスケールアウト/インなどでIPアドレスが変わってしまう可能性があるので、 このままでは、今後問題が発生
cloudpackブログ - (ELBとからめて)Hostヘッダでの振り分けをHAProxyでやってみる
本記事の構成はELBのIPアドレスが変更になった場合に問題が発生する可能性があるので 対策しておく必要があります。 HAProxyをDNS名で指定したバックエンドのIPアドレスが変わったらリロードするの記事が 参考になるかもしれません。 直接ではありませんが、Cloud Design Pattern（CDP）の「Multi Load Balancerパターン」に関する記事です。 このパターンの「利点」に下記のような複数SSL(HTTPS)に関する記載がありますが、ワイルドカード証明書を 利用する場合は、一つのELBで複数のSSL(HTTPS)サイトをまとめることも可能です。 同一のEC2で複数のSSL（HTTPS）を利用する場合も、SSL（HTTPS）ごとに ELBを用意することで可能となる。 図にすると下記のようになります。 上図は下記のようにDNS名ごとに別々のEC2に振り分けるところ
cloudpackブログ -NginxのアクセスログにELBの"400 Bad Request"エラー(まとめ)
ELBの下のNginxで、下記のアクセスログが頻繁にみられました。 ("x.x.x.x"はELBのIPアドレスです) x.x.x.x - [16/Nov/2012:00:00:17 +0900] 0.000 "-" 400 0 "-" "-" 0 0 x.x.x.x - [16/Nov/2012:00:00:18 +0900] 0.000 "-" 400 0 "-" "-" 0 0 x.x.x.x - [16/Nov/2012:00:00:18 +0900] 0.000 "-" 400 0 "-" "-" 0 0 上記の減少はElastic Load Balancer にぶら下がってる時の access logで非常に詳しく説明されていました。 つまり、ELBがsecond health checkと言われるコネクションを開いて閉じるだけの チェックを行い、それがNginxのアクセスログで
cloudpackブログ - ELB(スケールサイズ)とDNS(返されるIPアドレス)の関係(予想)
スズキです。 以前、下記の記事より、ELBのDNS名を名前解決して返ってくるIPアドレスは、最大8個であることがわかりました。 【AWS発表】 Elastic Load Balancingが東京リージョンでIPv6をサポート、新メトリクスもサポート、複数のIPアドレスを返すように 実際に、そこそこアクセス数の多いELBのDNS名を名前解決してみると、 下記のように8個(最大)のIPアドレスが帰ってきました。 $ nslookup suz-lab-000000000.ap-northeast-1.elb.amazonaws.com ... Name: suz-lab-000000000.ap-northeast-1.elb.amazonaws.com Address: 46.51.248.xxx Name: suz-lab-000000000.ap-northeast-1.elb.amazo
cloudpackブログ - tcpflowでELBの挙動を確認してみる
これまでは、パケットのモニタリングはtcpdumpでPostfixとSESの間のSMTPをのぞいてみるの記事のようにtcpdumpを利用していましたが、HTTPに関してはtcpflow — TCP Flow Recorderの出力が見易そうなので、試してみました。 インストールはyumで行う事ができます。 (リポジトリはrpmforgeです) # yum -y install tcpflow そして下記コマンドで80番ポートのモニタリングが始まります。 # tcpflow -cs -i eth0 port 80 tcpflow[4004]: listening on eth0 尚、指定しているオプションは下記の通りです。 -c : ファイルに書き出さずコンソールのみに出力 -s : 表示できない文字を”.”として出力 -i : モニタリング対象ネットワークインターフェース(eth0など)を
cloudpackブログ - ELBの挙動確認(Enable Load Balancer Generated Cookie Stickiness)
以前紹介した記事「ELBの挙動確認(Disable Stikiness)」にて、Cookieによるセッション維持を無効にした場合のELBの挙動を試しました。 そこで今回は、ELBが生成したCookieを元に、セッション維持する方法を有効にして確認してみました。 (テスト環境とテスト方法は前述の記事に同じです) まずは、二つのIPアドレスの一方に対して確認してみます。 # cat /etc/hosts xxx.xxx.xxx.xxx session-test.suz-lab.com #yyy.yyy.yyy.yyy session-test.suz-lab.com 普通にアクセスすると、前回同様に一方のAZのEC2に対して交互にアクセスされることがわかります。 # curl http://session-test.suz-lab.com/elb.php ELB_IPADDRESS : 10.
cloudpackブログ - ELBの挙動確認(Disable Stikiness)
ELBの挙動を確認するにあたり、以下構成を前提として進めます。 今回は、ELBのCookieによるセッション維持を無効にして試してみます。 まずは、ELBに振られているIPアドレスの確認です。 # nslookup test-000000000.ap-northeast-1.elb.amazonaws.com Name: test-000000000.ap-northeast-1.elb.amazonaws.com Address: xxx.xxx.xxx.xxx Name: test-000000000.ap-northeast-1.elb.amazonaws.com Address: yyy.yyy.yyy.yyy 二つ振られていることがわかります。 このELB経由で、下記のPHPにアクセスして挙動を確認してみます。 この際、ELB_IPADDRESSとEC2_IPADDRESSの値に
cloudpackブログ - ELBとHeartbeatでアクティブ/スタンバイ構成
今回は、先日書籍（Amazon Web Servicesクラウドデザインパターン設計ガイド）が発売された Cloud Design Pattern（CDP）の記事になります。 対象は「Floating IPパターン」です。 以前、上記のパターンをHeartbeat(Pacemaker)でEIPの付け替えの記事で紹介しました。 今回は、EIPで切り替えるのではなく、ELBを利用して切り替える方法を試してみます。 これは、本パターンの「その他」に記載されている下記の内容を実現する方法の一つになります。 予備サーバへの切り替えはEIPを用いず、ELBを利用して ヘルスチェックファイルの追加/削除で行う手段もある。 基本的には上記で紹介した「Heartbeat(Pacemaker)でEIPの付け替え」同様、Heartbeatで相互監視を行いアクティブなEC2に障害が発生した際、スタンバイのEC2に
cloudpackブログ - VPCのELBのサブネットを変更する
VPC上でELBを作成する場合は、VPCのSubnetとELBの関係(Availability Zone編)の記事で紹介した通り、 サブネットを設定する必要があり、そのサブネットは各AZで最大一個、複数指定することができます。 このELBに設定したサブネットは途中で変更することも可能です。 まず、ELBに下記のようなサブネット(10.0.0.0/24 Aゾーン)が指定されているとします。 上記のように選択されているサブネットを、下記のようなサブネット(10.0.2.0/24 Aゾーン)に変更してみますが、 エラーが出力され、変更できません。 エラーは下記のように出力されており、ELBに設定されているサブネットを変更するには、 少なくとも二つのAZがELBに設定されている必要があるようです。 In order to change the subnet attached to your loa
cloudpackブログ - ロードバランサー(ELB)経由でなくてもX-Forwarded-Forを付与する
Webサーバをロードバランサー(ELB)経由にする時に、Webサーバに設定されるリモートアドレスが、ユーザー(ブラウザ)のものからロードバランサーのものになってしまうことは有名な話だと思います。 その場合、ELBは(その他の多くのロードバランサーも)X-Forwarded-Forヘッダに、ユーザー(ブラウザ)のIPアドレスが設定されるので、以前紹介したApacheでREMOTE_ADDRをELB経由でも…(CentOS)の記事の方法等で対応することが可能です。 そして、あまり無いとは思いますがロードバランサー経由のWebサーバをインターネットからの直接アクセスに戻す場合もあるかと思います。 (このようなケースがあるとすれば、コスト削減や障害対応等の場合かと思います。) もし、アプリケーション等でX-Forwarded-Forヘッダを参照している場合、インターネットからの直接アクセスではX-
cloudpackブログ - SSL Termination(ELB)でアプリ(EC2)がHTTPSのチェックを行えない場合
今回は、先日書籍（Amazon Web Servicesクラウドデザインパターン設計ガイド）が発売されたCloud Design Pattern（CDP）の記事になります。 対象は「Multi Load Balancerパターン」です。 ELBのSSL Termination機能で、SSLの処理をEC2(Webサーバ)ではなくELBに行わせることが可能ですが、それに伴い、このパターンの「注意点」に下記の記載があります。 ELBのSSL Termination機能を用いるとEC2側はHTTPでリクエストを受けることになるのでアプリケーションでのHTTPS接続の判定が難しくなる。 直接EC2のWebサーバでSSLの設定をして、HTTPSでのアクセスを行う場合はPHPの場合、下記の環境変数でHTTPSの接続かどうかチェックしている場合が多いとお思います。 ($_SERVER[“HTTPS”]の有
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
