• AWSとVPN接続したら応答が無くなる時の対応

    おはようございます。インフラ宮下です。 AWSのVPCとオフィスをVPNで接続するケースは良くありますが、構成によってはダウンロードしたconfigではうまく動作しない事があります。 今回は、以下の環境の時に変更しなければいけなかった設定をまとめたいと思います。 1)AWSの接続環境 [shell]リージョン:シンガポール ルータ:YAMAHA RTX 1200 経路情報:Static[/shell] 2)VPNのconfigを確認 VPN Connectionsを作成した後にconfigをダウンロードすると設定項目として、IKE・IPSec・Tunnel Interface・Static Route の4項目がありますのでそれぞれの内容について確認しましょう。 ・IKE [shell] tunnel select 1 ipsec ike encryption 1 aes-cbc ipsec ike group 1 modp1024 ipsec ike hash 1 sha ipsec ike pre-shared-key 1 text y7Nn93e7fJHWQrUaabbccdd112233[/shell] IKEについては、configそのまま流用で問題ないでしょう。keyは個々に違いますので正しいKeyにしてください。 トンネル番号は、既に「1」を使っている場合は違う数字にしてください。(以降のID表記も忘れずに変える) ・IPSec [shell] ipsec tunnel 201 ipsec sa policy 201 1 esp aes-cbc sha-hmac ipsec ike duration ipsec-sa 1 3600 ipsec ike pfs 1 on ipsec tunnel outer df-bit clear ipsec ike keepalive use 1 on dpd 10 3[/shell]
    ...
  • AWS(VPC)上でheartbeat3でlvsを構成する話

    ※1年以上前の旧い記事なのでご注意ください。※ こんにちは。プラットフォームの小宮です。 今回は、ELBは高いのでスモールスタートだからLVSを構築しましょうという趣旨ですすめた記録です。 最初に書くのもなんですが、LVSでWEBもDBも負荷分散しちゃおうぜということだったんですが、結果的にはWEB側はやっぱELBにという話になりました。 (公私混同フラットNWであることを顧客に説明するのが大変だという話とSSLとかスケールとか運用の利便性等で。) 普段よりは気をつける点: ・環境がAWS(インスタンスを気軽に作り直してChange Source/Dest CheckをDisableにし忘れる等に要注意) ・クライアントがグローバル越しだとDSRできない(エッジルータでENIとIPが合わないパケットが破棄される) ・フラットなNW構成でないとDSRできない(これは普段通りだけど気をつけるポイント) ・複数NWでNATインスタンスが必要になる等の特殊事情(だからNWは1つだけにしました) ・DBはDSR、WEBはNATで分散する ・VIPは使えるけどAWS的な管理上APIサーバと通信して切り替える必要がある ・AWS的な管理上splitbrainは実質起こらないがどっちについてるか確認必要 ・AWS的な制約でマルチキャストは使えないのでHA通信はunicastを用いる ・証明書は負荷分散ライセンスとかでWEBサーバ側で管理する 目次: ・基本構成 ・分散対象側の基本的な設定 ・ipvsadmで負荷分散の単体テスト ・heartbeatの導入設定 ・ldirectordの導入設定 ・EIP・PrivateIP移動シェル作成 ・リソース設定 ・インスタンスコピーの際の作業 ・切替テスト ・ハマったところ ・基本構成 LVS01(主系) LVS02(待機系) web2台、配信サーバ2台、db2台に対しそれぞれ80と443、3306readを分散 lvs01:172.18.1.23 lvs02:172.18.1.25 db-r-vip:172.18.1.200 web-vip:172.18.1.199 db-client:web(local) web-client:any(global) real-db:172.18.1.220,221 real-web:172.18.1.33,34 webの分散方式:NAT dbの分散方式:DSR 設計書ではフロントセグメントとバックセグメントに分かれていたのですが、AWS的な仕様上LVSと組み合わせる為にはフラットにせざるをえませんでした。 ⇒クライアントがグローバル越しのWEBサーバはエッジルータでENIとIPが一致しないパケットが破棄される為分散方式はDSRは無理でNATしか利用できない ※こちらのスライドの17枚目が論拠です。 ⇒分散方式がNATだとリアルサーバは負荷分散サーバをデフォルトGWとして指定する必要がある ⇒NATインスタンスはNICを一つしか持つことができない仕様だがデフォルトGWは同一セグメントでないと指定できない ⇒少なくともWEBはセグメント1つにしないとLVS+VPCでは負荷分散できないがDBとWEBの分散は同じLVSで一緒にやりたいしもうNWセグメントは1つでいいや ⇒バックセグメントが無くてもVPCだしSecurityGroupの設定さえまともなら大丈夫 というような事情によりまして設計書の仕様変更をしないとどうにもなりませんでした。 なんでHAproxyじゃないのかというと、運用上不慣れだからとLVSのがパフォーマンスがいいらしいから。DBだけでもDSRできるのは嬉しいです。
    ...
  • VPC上でPrivateIPアドレスを付け替える

    こんにちは。小宮です。 ちょっと前にAWSのVPC上でVIP(VirtualIPアドレス)を移動させる需要があって検証したのですが、 個人的にメモってただけだったのと、質問される機会が数回ありましたので簡単にですが投稿しておきます。 なんらかのクラスタ構成をVPC上で扱う際、VPC上でPrivateIPアドレスを付け替える必要が生じた場合、 awsなので切替スクリプトをAPI使うように修正しないと内部はともかく外部から打ったPINGへの応答が帰ってこない。 つまりVIPが移動したことになりません。 つまり、以下のような感じになります 落とすときは、IF落としてかつCLIも実行する [shell]ifconfig eth0:1 down ec2-unassign-private-addresses –network-interface eni-4b649*** –secondary-private-ip-address 10.0.0.96[/shell] ※ec2-unassign-private-addressesの短縮バージョンはec2upip 起動するときも、IF起動かつCLI実行する [shell]ifconfig eth0:1 up ec2-assign-private-ip-addresses –network-interface eni-70609*** –secondary-private-ip-address 10.0.0.96[/shell] ※ec2-assign-private-ip-addressesの短縮バージョンはec2apip 切替元のENI:eni-4b649*** 切替先のENI:eni-70609*** 参考: VPC 内の EC2 インスタンス に複数EIPを付与する ec2-assign-private-ip-addresses - Amazon Elastic Compute Cloud ec2-unassign-private-ip-addresses - Amazon Elastic Compute Cloud もし、EIPが紐づいてるENIをデタッチ、アタッチしたい場合、以下のような感じ。(たぶん(自分で試してないです)) [shell]ec2-detach-network-interface ${eni_attach_id} ec2-attach-network-interface ${ENI_ID} –instance ${target_instance_id} –device-index ${TARGET_DEVICE_INDEX}[/shell]
    ...
  • Chef-Soloでレシピを書く前の環境について(Vagrantfile,role,node,data_bags)

    こんにちは。小宮です。 いつのまにか今年の前半が終了しました。宇治金時がおいしい季節になってしまったようです。 それはともかく前回の続きです。 今回はChef-Soloのレシピを書く前の環境の定義などまでを書きます。 Chef用語などは軽く解説してる、今日から使い始めるChefを見ていただくか定番の入門Chef Soloを見ていただくのが早いんではないかと思います。 Automated infrastructure is on the menuも英語ですがわかりやすいです。 やりたいこととしては以下のとおりです。 Vagrantfileを書いて仮想インスタンスをたてる chefレポジトリを作る chefクックブックを作る nodeを定義する roleを定義する data_bagsを定義する ★今回はここまで★ レシピを書く レシピをノードに適用する serverspecテストを書く テストを実環境に実行する テストの構成: chef-solo元のadmserver:10.0.0.93 knife-solo適用クライアントwebserver:10.0.0.240 knife-solo適用クライアントdbserver:10.0.0.241 全てCentOS5.8です。 ・AWSの環境変数を定義 AWSのVPC上なので適宜定義しておきます [shell]# cd # vi .ec2 export AWS_ACCESS_KEY_ID=****** export AWS_SECRET_ACCESS_KEY=******* export AWS_KEYPAIR_NAME=xxx-key export AWS_PRIVATE_KEY_PATH=/root/.ssh/xxx-key # source .ec2[/shell] ・VagrantFileを書く vagrant initを実行するとVagrantfileができますのでそれを編集し、
    ...
  • Chef-SoloとVagrantの導入(VPC環境)

    こんにちは。プラットフォームの小宮です。 最近chef流行ってますね。 せっかくだからこの波に乗ってプロダクト環境に合わせてやってみよう的な記事を書こうかと思います。 さっさとServerspecまでたどり着きたいんですが、今回は導入のみの記事でレシピなどはまた次回以降に。 やってみよう的なレベルなのでリファクタリングし甲斐のあるレシピになる予感がします。 さて今回Chef化を試みる環境はVPC上に移行する話になってます。(構成はweb2、db2、stg1、nat1です。ELB利用。soloで十分な感じ。) Vagrant-awsでVPCつかう方法が可能なようなので、Vagrantを使用して構成管理を行いつつKnife-soloも使うことにします。 vagrantとsahara連携でOSの状態を保存してロールバックということが可能となります。 knife-soloだと/sbin等の下のrubyを消して入れ替えようとしてしまうことがあるらしいので、アプリケーションにおいてrubyを使用しないことを確認しておきます。 vagrantを入れるのでruby1.8.7より上のバージョンをrbenvで入れます。 (CentOS5系の場合。6系や他のディストリビューションでは別途ruby -vで確認してください) 実は、Chef-Clientを/opt/chefの下に入れた段階で以下のようにPATHを通しておけばrubyのバージョンは気にしなくてもよいかもしれません。 [shell]# curl -L https://www.opscode.com/chef/install.sh | bash # export PATH=$PATH:/opt/chef/embedded/bin/ # vi ~/.bashrc PATHをとおしておく[/shell] gemでchefを入れるのは古いやりかたみたいですね。 ・最初にOracleVirtualBoxを導入 入れる理由はVagrant-awsでインスタンスの起動と管理を行うため。 [shell]cat /etc/redhat-release CentOS release 5.8 (Final) yum install libXmu libXt mesa-libGL qt qt-x11 SDL wget http://download.virtualbox.org/virtualbox/4.2.12/VirtualBox-4.2-4.2.12_84980_el5-1.x86_64.rpm rpm -ivh VirtualBox-4.2-4.2.12_84980_el5-1.x86_64.rpm[/shell] ・ruby-1.8.7より新しいバージョンを導入(必要な場合) [shell]yum -y install zlib-devel readline-devel openssl-devel yum install ruby ruby-devel rdoc irb rubygems yum install git –enablerepo=rpmforge[/shell]
    ...
  • 裏セグメントからyumやwget等したい場合の設定

    裏セグメントのホスト(たとえばVPCのEIPついてないのとかDBやNASなど裏においときたいやつ) から名前解決とかメールとかyumとかwgetとか時刻同期とかメールしたい! という場合の設定についてざっくりまとめさせていただきます。 とりあえず2パターンあります。 NATする(AWSの場合NATインスタンスを使う)パターンと、 グローバル通信できる管理サーバにソフトウェアを入れて解決するパターン。 ★NATする(AWSの場合NATインスタンスを使う)パターン db側はInternetGatewayつけてなくてパブリックでなくローカルなルーティングな場合、 名前解決をはじめ外に出られないです。(※) NATインスタンスを作るのも勿体ないと、複数NICがついたwebをnat化しようとしたところ、 マルチインタフェースなインスタンスはNATの出口に出来ない模様でした。 (※)最近新しくとったアカウントはVPCオンリーになっていてそちらだとグローバルIPがどんどん勝手に振られるようです。。(EIPつけざるをえない仕様) NATインスタンス作成方法は以下URLから Amazon VPCトレーニング-NATインスタンスの作成方法 VPC詳細 -ほぼ週刊AWSマイスターシリーズ第7回- Amazon VPCでNATを使ってPublic SubnetとPrivate Subnetを分ける 一番上のスライドのとおりでnatインスタンスを作成可能。 ざっくりいうと、 VPCサブネットをつくり、 “ami-vpc-nat"AMIでNATインスタンスを作成し、 NATインスタンスの"Change Source/DestCheck"をDisableにし、 NATインスタンスにEIPをアソシエートし、 PublicSubnetのRouterTableにNATインスタンスのIDを追加し、 必要に応じてNATインスタンスのSecurityGroupを設定する そのほか、一般的なルータ化設定方法と同様に、 インスタンス作成後にiptablesでnatのルール設定が必要になる模様。 /sbin/iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/16 -j MASQUERADE service iptables save iptables --list -t nat 上記スライドのとおりNATインスタンスをデフォルトゲートウェイにするルーティング設定も必要 forwardingの設定も必要
    ...