移行作業

移行を実施する当日の作業を説明します。


作業の概要

NO. 作業項目 作業対象
1 新ロードバランサーを構築し、事前に準備していた設定を適用する Managed Load Balancer (MLB-01)
2 ファイアウォールにて、スタティックルートを変更する vSRX または Managed Firewall

1. 新ロードバランサーを構築し、事前に準備していた設定を適用する


Managed Load Balancer に、[事前準備 ]で準備しておいた設定を、「Managed Load Balancer の構築」で反映させます。

  • 作業対象:Managed Load Balancer (MLB-01)
ManagedLB

作業手順

① Managed Load Balancerの一覧画面より、構築するManaged Load Balancerリソースのアクションプルダウンから「Managed Load Balancerの構築」をクリックします。

ManagedLB

② Managed Load Balancerの構築確認画面が表示されるので、「Managed Load Balancerの構築」をクリックします。

ManagedLB

注釈

  • Managed Load Balancerの構築が完了した時点から課金が開始されます。
  • 構築完了までには15分程度かかります。
  • ポリシーを1つも作成していない場合は「Managed Load Balancerの構築」は選択できません。

③ Managed Load Balancer の構築が完了し、ステータスが 「ACTIVE」になったことを確認します。


2. ファイアウォールにて、スタティックルートを変更する


ファイアウォールにてスタティックルートを変更することで、通信が新ロードバランサー(Managed Load Balancer)側に切替えられます。

  • 作業対象:vSRX または Managed Firewall (お客様ご利用のファイアウォールにて、本手順を実施してください。)

警告

  • この手順において、1秒程度の通信断が発生します
※本手順実施後、疎通できない等の問題が発生した場合は、切り戻し手順を実施してください。
ManagedLB

作業手順

〈vSRXの場合〉

  • 作業手順

① コンソールまたはSSHでvSRXへアクセスします。アクセスしたCLIにて下記②~⑥の後続の作業を実施します。

 ※ vSRXへのアクセスについては、 こちら の「vSRXへのログイン(CLIへのアクセス方法(SSH))」の手順をご参考ください。


② シェルコマンドモードからオペレーションモード、コンフィグレーションモードに入ります。

コマンド例)「cli」「configure」
root@:∼ # cli
root> configure
Entering configuration mode

③ 旧ロードバランサー向けに設定した経路を削除します。

コマンド例)「delete routing-options static route 172.16.100.0/24 next-hop 192.168.1.251」
[edit]
root# delete routing-options static route 172.16.100.0/24 next-hop 192.168.1.251

④ 新ロードバランサー向けの経路を設定します。

コマンド例)「set routing-options static route 172.16.100.0/24 next-hop 192.168.1.241」
[edit]
root# set routing-options static route 172.16.100.0/24 next-hop 192.168.1.241

⑤ 設定をコミットします。

コマンド例)「commit」
[edit]
root# commit
commit complete

警告

  • この手順で1秒程度の通信断が発生します。
  • しばらくしても通信断の状態のままとなる場合は切り戻し作業(こちら)を検討してください。

⑥ オペレーションモードに戻り、経路が設定されているか確認をします。

コマンド例)「exit」「show configuration routing-options」
設定した経路が表示されることを確認します。
[edit]
root# exit
Exiting configuration mode

root> show configuration routing-options
static {
    route 100.64.0.0/16 next-hop 100.64.161.1;
    route 0.0.0.0/0 next-hop 192.168.0.100;
    route 172.16.100.0/24 next-hop 192.168.1.241;
}

これで経路が変更されました。

※ 冗長構成をとっている場合は、Standby機に対しても同じ作業を行ってください。

  • 経路設定変更後の疎通確認手順

① vSRXから仮想サーバ(192.168.2.11 / 192.168.2.12)に対してPingでの通信ができること確認します。

コマンド例)「ping 192.168.2.11」
root> ping 192.168.2.11
PING 192.168.2.11(192.168.2.11): 56 data bytes
64 bytes from 192.168.2.11: icmp_seq=1 ttl=64 time=1.600 ms
64 bytes from 192.168.2.11: icmp_seq=2 ttl=64 time=1.565 ms
64 bytes from 192.168.2.11: icmp_seq=3 ttl=64 time=1.082 ms
64 bytes from 192.168.2.11: icmp_seq=4 ttl=64 time=1.135 ms
^C
--- 192.168.2.11 ping statistics ---
5 packets transmitted, 4 packets received, 20% packet loss
round-trip min/avg/max/stddev = 1.082/1.345/1.600/0.238 ms

② 仮想サーバから応答があれば完了です。


〈Managed Firewallの場合〉

  • 作業手順

下記①~③の作業手順ついては、GUI画面の例が記載される こちら の「ルーティング 変更(編集/複製/削除)」の手順をご参考ください。

① Managed FirewallのGUIからルーティング変更画面にアクセスします。


② 仮想サーバ向けで Gatewayの設定値に旧ロードバランサーのIPアドレスが設定されているルーティング定義について、旧ロードバランサーのIPアドレスを新ロードバランサーのIPアドレスに変更します。


③ 「変更の保存」をクリックし、設定をデバイスへ適用します。

これで経路が変更されました。

※ Managed Firewallで設定変更作業をした内容は、自動でActive/Standby機に同期されるため、両方のリソースでの作業は不要です。

警告

  • この手順で1秒程度の通信断が発生します。
  • しばらくしても通信断の状態のままとなる場合は切り戻し作業(こちら)を検討してください。

  • 経路設定変更後の疎通確認手順

① Clientから仮想サーバ(192.168.2.11 / 192.168.2.12)に対してPingでの通信ができること確認します。(Managed FirewallはSSH接続ができないためClientから疎通確認を行います)

コマンド例)「ping 192.168.2.11」
root> ping 192.168.2.11
PING 192.168.2.11(192.168.2.11): 56 data bytes
64 bytes from 192.168.2.11: icmp_seq=1 ttl=64 time=1.600 ms
64 bytes from 192.168.2.11: icmp_seq=2 ttl=64 time=1.565 ms
64 bytes from 192.168.2.11: icmp_seq=3 ttl=64 time=1.082 ms
64 bytes from 192.168.2.11: icmp_seq=4 ttl=64 time=1.135 ms
^C
--- 192.168.2.11 ping statistics ---
5 packets transmitted, 4 packets received, 20% packet loss
round-trip min/avg/max/stddev = 1.082/1.345/1.600/0.238 ms

② 仮想サーバから応答があれば完了です。


正常性の確認

ManagedLB

  • 関係する各リソース間の疎通確認の方法を移行手順とあわせて記載しておりますので、それらを参照の上実施してください。
  • 負荷分散が正しく行われていることを確認してください。
    • お客さまのご利用のプロトコル・サービス内容によって方法が異なりますので、負荷分散先のサーバーが異なっていることが分かるようなテスト方法をあらかじめご用意いただき、アクセステストを実施してください。