20150226_JAWS_UG札幌

Copyright © 2014 AGREX INC. All rights reserved.
事例紹介
プライベートネットワークにおける
FTPサーバの可用性向上
2015.02.26
札幌事業所

Copyright © 2014 AGREX INC. All rights reserved. 2
自己紹介
松井美佳
(株)アグレックス札幌事業所
・2014年入社
・AWSグループ所属
・AWS暦…7ヶ月!!
・好きなAWSサービス…Route53
・AWS認定資格…3月合格予定!!
↑札幌でも受験可能予定!!
2015年3月2日(月)から開始
毎週月曜日・水曜日
AWS利用前
AWS利用開始後

本日のお話

本日のお話
お客様よりこんなご要望･･･
社内からAWS上のFTPサーバにVPN経由で通信したい!!
FTPサーバは、24時間365日絶対に落ちないでほしい!!
FTPサーバの可用性を上げるために
冗長化しましょう!!
お客様

可用性向上を狙った冗長化

①ELBを使用した場合の冗長化
②Route53を使用した場合の冗長化
※ELBとは、Elastic Load Balancingの略。（＝ロードバランサ）
※Route53とは、（とても親切な）DNSサービス。
ELBはこのマーク!
Route53はこのマーク!
DNSサーバがクエリの送受信に利用する「UDPポート53番」が由来。

※ELB：アプリケーションの負荷分散と可用性向上を同時に実現するサービス
EC2EC2EC2EC2
ELB ELB
継続アクセス可能!!
大量アクセス!?
障害発生!?
負荷分散!!

②Route53を利用した場合の冗長化
※1つのホスト名に2つの異なるIPアドレス設定可能＋ヘルスチェック機能
→DNSフェイルオーバー機能!!
EC2EC2EC2EC2
Route53 Route53
AWSの冗長化
プライマリーIPへ接続!! セカンダリーIPへ接続!!
hoge.jp hoge.jp
54.aa.aa.aa 54.aa.aa.aa54.bb.bb.bb 54.bb.bb.bb
プライマリーIP セカンダリーIP

※ELBとは、Elastic Load Balancingの略。（＝ロードバランサ）
※Route53とは、（とても親切な）DNSサービス。
ELBはこのマーク!
Route53はこのマーク!

→ELBはHTTP・HTTPS・TCP・SSLプロトコルでの通信が可能
(25,80,443,465,587,1024-65535)
→負荷分散＝リクエストが分散
EC2EC2
ELB
FTPポート(21)からの通信ができません!!
※コントロールコネクション：ログイン・セッション
ファイル転送方法の命令・応答
※データコネクション：転送されるデータの送受信
コントロールコネクションとデータコネクションが
別のインスタンスに繋がる可能性がある!!

→ヘルスチェック元：世界各所に分散したHealth Checkerたち
→ヘルスチェックはインターネット越しに行われる
EC2EC2
Route53
プライベートネットワーク上では
ヘルスチェックがかけられない！!

困ったときは…

困ったときは…
助けを求めましょう!!
AWSの設計・運用方の
ノウハウがぎっしり!!
問題解決方法もあり!!
http://aws.clouddesignpattern.org/

CDP:Floating IP パターン
Floating IP パターン = IPアドレスの動的な移動
(例)
①障害発生した既存EC2インスタンスのEIPをデタッチ
②外したEIPを別のEC2インスタンスにアタッチ
○APIを利用してスクリプトを用いて自動化可能
○今回は、プライベートIPを付け替えたい…
→ネットワークインターフェース(ENI)の付け替え!!
※EIP(Elastic IP Address)とは、AWSで利用できる固定のグローバルIPアドレス
※ENI(Elastic Network Interface)とは、VPC のインスタンスにアタッチできる
仮想ネットワークインターフェイス
たったこれだけ!!
http://aws.clouddesignpattern.org/index.php/CDP:Floating_IP
%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3

FTPサーバ冗長化構成図①
監視サーバ
FTPサーバ①
FTPサーバ②
FTP通信
ヘルスチェック
ファイル同期
社
内
ネ
ッ
ト
ワ
ー
ク
VPN
eth0:172.16.11.10
eth0:172.16.11.20
eth1:172.16.11.30

FTPサーバ冗長化構成図②
FTPサーバ①
FTPサーバ②
FTP通信
ファイル同期
社
内
ネ
ッ
ト
ワ
ー
ク
VPN
eth0:172.16.11.10
eth0:172.16.11.20
eth1:172.16.11.30
FTPサーバ①異常検知!!
ENI(eth1)デタッチ!!
ENI(eth1)アタッチ!!
監視サーバ

実装手順

実装手順
①FTPサーバ(EC2)を2台立てる!!
※FTPサーバソフト導入・設定
②監視用サーバ(EC2)を立てる!!
※立てる際にはIAM Roleを付ける
③ヘルスチェック＋フェイルオーバー用のシェルスクリプトを作成!!
④cronで③で作成したのシェルが定期的に実行するよう設定!!

②監視用サーバ(EC2)を立てる!!
※立てる際にはIAM Roleを付ける!!
※IAM Roleとは、インスタンスに(任意の)APIのアクセス権限を
与えることのできる機能
以下の権限付与しています
・ENIアタッチ
・ENIデタッチ
実装手順

③ヘルスチェック＋フェイルオーバー用のシェルスクリプトを作成!!
FTPサーバへの
(障害検知された) インスタン
スからENIをデタッチ
もう片方のインスタンスへ
ENIをアタッチ
・pingでの疎通確認
・FTPログイン確認
etc..． ※ENIのデタッチ確認後…
異常
正常
フェイルオーバー開始!!
フェイルオーバー完了!!
実装手順
開始
終了

課題点

課題点
①AZについて
※同一のAZでのみ実装可能
→ENIの付け替えが同一のAZ内でしかできないため
②スクリプトに用いているAWS APIのリクエストについて
③監視サーバー自身の障害対応について

(例)
「ENIデタッチ!!」というAPIリクエストを飛ばす
作業が完了したかどうかは自力で確認するしかない!!
課題点
「ENIデタッチを受け付けました」という返答が返ってくる
「ENIデタッチが完了」したかどうかがわからない…

FTPサーバへの
(障害検知された) インスタンスから
ENIをデタッチ
もう片方のインスタンスへ
ENIをアタッチ
デタッチ確認作業
異常
正常
デタッチ確認作業デタッチ確認
デタッチが
完了したか
10秒待つ
Yes
No
課題点
開始
終了
開始
終了

★AWS CLIのバージョン1.6.0以降より、
リクエストが完了するまで待ち合わせる機能が利用可能!!
→サブコマンドに「--wait」を追加するだけ!!
現在「--wait」が利用可能なコマンドたち(2015/02/22確認)
・bundle-task-complete
・conversion-task-cancelled
・conversion-task-completed
・conversion-task-deleted
・customer-gateway-available
・export-task-cancelled
・export-task-completed
・instance-running
・instance-stopped
・instance-terminated
・snapshot-completed
・subnet-available
・volume-available
・volume-deleted
・volume-in-use
・vpc-available
・vpn-connection-available
・vpn-connection-deleted
今後増えていくことを期待!!
課題点
同期呼び出し

③監視サーバー障害対応について
【現在の障害対応】 (1)監視サーバの状態チェック
(2)監視サーバ障害発生
(3)サーバ管理者へ
アラートメールを飛ばす
(4)監視サーバのバックアップ(AMI)よりEC2復元
CloudWatch
Alert Mail
(SNS経由)
AMI
EC2
EC2サーバ管理者
監視
サーバ
課題点
(4)復旧完了!!
監視
サーバ
手間…
時間…
コスト…

③監視サーバー障害対応について
【将来的に導入したい障害対応】
AutoRecoveryで自動復旧!!
○導入手順
・CloudWatchのアラーム設定のみ
(StatusCheckFailed_Systemのメトリクスのみ設定可能)
(1)監視サーバの
状態チェック
CloudWatch EC2
監視
サーバ
課題点
(3)サーバをstop/start(=物理ホスト移動)
EC2
(4)復旧完了!!監視
サーバ
現在はUS-EASTのみ対応。
日本にも対応されれば、ぜひ導入したい!!
・ネットワーク接続の喪失
・システム電源の喪失
・物理ホストのソフトウェアの問題
・物理ホストのハードウェアの問題

(1)監視サーバの
状態チェック
CloudWatch EC2
監視
サーバ
補足：AutoRecoveryのユースケース
EC2
(4)復旧完了!!監視
サーバ
1.Webサーバのような「停めることを許されない」ケース
2.監視サーバのような「少しの時間停めてもかまわない」ケース
復旧まで、数分のタイムラグ発生!!
(3)サーバをstop/start(=物理ホスト移動)
非冗長化で…

最後に･･･

20150226_JAWS_UG札幌

Recommended

Recommended

More Related Content

Similar to 20150226_JAWS_UG札幌

Similar to 20150226_JAWS_UG札幌 (20)

Recently uploaded

Recently uploaded (10)

20150226_JAWS_UG札幌