ソフトウェアLB パラメータシート（nginx / HAProxy）

説明

使い方

収録内容

全10シート。各シートに書いてあることは次のとおりです（ファイルの「目次」シートより）。

前提共通設計

製品・構成・OS・運用の方針

設定項目（14件）

製品・版数・台数・OS・アドレス・仮想IP・公開するサービス・証明書・バックエンド・接続元の制限・アクセスログ・置き場所と保持・監視項目・設定の管理・変更の記録

設定値振り分け設定

待ち受け・振り分け先・転送・ログ。製品ごとの名前を並記

設定項目（10件）

受けるアドレスとポート・証明書・バックエンドの定義・振り分け方式・維持・元のクライアントIP・待ち時間・受け付ける大きさ・アクセスログ・状態の確認

設計ヘルスチェック

★無償版のnginxには能動的な確認が無い

項目（24件）

★受動的な確認・★能動的な確認・★無償版で使うなら・戻り方・確認の内容・★全部落ちたとき・監視の送信元・記録・保守で外すとき・★試験・書き方・★受動的な確認と能動的な確認は、別のものとして扱う。・受動的は、実際の利用者の通信が失敗したことを数えて振り分け先から外す。・つまり、落ちてから外れるまでの間、何人かは必ずエラーを受け取る。・能動的は、定期的に自分から確かめるので、利用者が踏む前に外せる。・★nginx の無償版には能動的な確認が無い（有償版の機能）。・HAProxy は無償版でも能動的に確認できる。製品を選ぶ段階で効く違いなので、・「LBとして同じ」と思って選ばない。ここを設計に書いて判断の根拠にする。・★無償版で使うなら、受動的な設定の値を明示する。・既定（1回の失敗・10秒）のままだと、一時的な失敗でも外れる。・★「全部落ちた」を監視で拾う。1台ずつの監視だけでは足りない。・全メンバーが落ちると、LBはただエラーを返すだけになる。・・1台止める試験では、止めた直後の数リクエストが失敗する挙動まで見る。・それを許容できるかが、受動的な確認を選べるかの判断になる。

設計反映と冗長

★1つの誤字で全部落ちる。★冗長は自分で組む

項目（25件）

★設定の検査・★反映の方法・反映の確認・★冗長の組み方・★同時に現用になる・★何を落ちたと見るか・切り替えの実測・切り戻し・★2台の設定・退避・書き方・★反映の前に必ず検査する。1つの誤字で全サービスが落ちる。・装置なら画面が受け付けないところを、テキストの設定はそのまま通してしまう。・検査を手順の必須項目にし、通ってから反映する。・★再読み込みと再起動を取り違えない。・再読み込みは既存の接続を保ったまま新しい設定にする。再起動は切れる。・手順書にどちらを使うか明記する。・★冗長は自分で組む。装置と違って筐体のHAが無いので、・何も入れなければ1台構成のままになる。ここが設計のいちばんの山になる。・★監視の経路を2本以上にする。1本だと、その経路が切れたときに・両方が現用になり、同じIPが2つ存在する状態になる。・★プロセスが生きていることと、応答することは別。・プロセス監視だけだと、応答しない状態で切り替わらない。・・2台に同じ設定を配る仕組みを決める。手でコピーすると必ずずれる。・・切り替えは構築中に実測する。断の長さを記録する。

設計OSと資源

★LBの設定だけ上げても増えない。OS側の上限が効く

項目（24件）

★同時接続数・★ファイル記述子・★送信元ポートの枯渇・接続の使い回し・メモリ・★OS側の設定・★ファイアウォール・ログの領域・監視・★性能の実測・書き方・★同時接続数はLB側とOS側の両方を設計する。・LBの設定だけ上げても、OS側の上限に当たれば増えない。・装置なら公称値があるが、ソフトウェアLBは自分で決める部分になる。・★バックエンドへ出る送信元ポートの枯渇に注意する。・バックエンドの台数が少ないほど早く当たる。・「最初は動いていたのに、途中から繋がらない」の原因になる。・★OS側の設定はRHELのシートで決める。別々に見ない。・LB側の設定だけを見ていると、上限に当たっている原因が分からない。・★性能は実測する。装置の公称値のような数字が無いので、・想定の接続数で試した結果が、唯一の根拠になる。・・接続数・資源の使用量・振り分け先の状態を監視項目一覧に入れる。・装置のような画面が無いので、監視しないと何も見えない。・・ファイアウォールは受ける側と出る側の両方を許可する。片方だけだと通らない。

確認確認コマンド集

落ちたときにどう振る舞うかまで確認する

注意設定時の注意

この構成で実際に起きる失敗と、その回避手順