LoginSignup
12
7

More than 5 years have passed since last update.

@testnin2(Shinobu Yasuda)

vRouter5400(Vyatta Gateway Appliance)からvRouter5600(Virtual Router Appliance)への移行注意点(1)

Last updated at Posted at 2017-07-24

1.はじめに

本記事では、IBM Cloud(Bluemix Infrastructure/SoftLayer)におけるVyatta Gateway Appliance(vRouter 5400)とVirtual Router Appliance(vRouter 5600)の違いを説明し、5400から5600への移行の手がかりにすることを目標とします。
残念ながらVyatta Gateway Appliance(vRouter 5400)は、

  • 2017年9月1日にEOM(End of Market：販売終了）
  • 2018年2月20日にEOS(End of Support：サポート終了)

を迎えます。公式の移行ガイドみたいなものは存在しないため、網羅的に説明すること難しい状況です。よって、著者が気づいた点や指摘を受けた点を、ベストエフォートで適宜更新していく予定です。
この記事では移行前の準備にフォーカスし、具体的な5400/5600の違いは以下で紹介したいと思います。
vRouter5400(Vyatta Gateway Appliance)からvRouter5600(Virtual Router Appliance)への移行注意点(2)

参考資料：

2. vRouter5400/5600の違いの概略

  • vRouter 5400の後継がvRouter 5600ですが、残念ながら後方互換機能は提供していません。よって、5400の構成スクリプトを5600でそのまま実行することはできません。 基本的な設定方法は従来通り、Operation ModeとConfiguration Modeを使い分けて設定します。
  • IBM Cloudでは、Vyatta Gateway Appliance(vRouter 5400)は複数VLANを関連づけ（associated)、routedモード/bypassモードを切り替えることによって、VRRPに割り当てられたVIP経由で関連づけたVLANに対する経路をVyatta Gateway Appliance経由にすることがCustomer Portalから可能でした。同様の機能は、Virtual Router Appliance(vRouter 5600)でも行うことが可能です。
  • 従来のvRouter 5400は受け付けたパケットをLinux Kernelで処理していましたが、これだけでは10Gbpsのような高速なNIC環境では割り込み処理が追いついていませんでした。十分な性能上の恩恵を受けるために、vRouter 5600からはコントロールプレーン（転送経路の決定）とデータプレーン（実際の転送）の処理部分を分離し、特にデータプレーンにおいてIntel DPDKを利用してユーザーランドで効率的に処理を行うことを目指しました。そのため、データプレーン用のインターフェースが設けられたり、iptablesを利用しないユーザーランドで処理するフィルタリング方式に変更されています。slideshare上にある≪ハイパフォーマンス仮想Router≫Brocade Vyatta 5600 vRouter アーキテクチャー概要もご参照ください。
  • vRouterのOS費用（その他費用は変更ありません）がvRouter 5400では$219でしたが、vRouter5600では以下のように変更されています。
    • Single Processorモデルでは$219のまま据え置き。
    • Dual Processorモデルでは$399に。
vRouter5400(VGA)
vyatta@vga01:~$ show version
Version:      VSE6.7R10
Description:  Brocade vRouter 5415 6.7 R10
Copyright:    2016 Brocade Communications Systems, Inc.
Built by:     autobuild@vyatta.com
Built on:     Thu Jan 28 01:12:37 UTC 2016
Build ID:     1601280114-ec94d79
System type:  Intel 64bit
Boot via:     image
HW model:     PIO-628U-TR4T+-ST031
HW S/N:       A16640424B01844
HW UUID:      00000000-0000-0000-0000-002590FA8E5C
Uptime:       15:49:23 up 6 days, 21:03,  1 user,  load average: 0.07, 0.20, 0.27
vRouter5600(VRA)
vyatta@vga02:~$ show version
Version:      5.2R5S3
Description:  Brocade Vyatta Network OS 5600 5.2R5S3 Standard License
License:      Standard
Built on:     Fri Jun 30 13:09:25 UTC 2017
System type:  Intel 64bit
Boot via:     image
HW model:     PIO-628U-TR4T+-ST031
HW S/N:       A16640427510214
HW UUID:      00000000-0000-0000-0000-0CC47AD310C0
Uptime:       01:49:12 up 9 min,  1 user,  load average: 0.42, 0.46, 0.34

具体的な違いとしては、後述の記事で記載します。

3. 移行方針

移行方針としては以下の方法が考えられます。

3.1 新規にvRouter 5600を構築する方法。

メリット

  • 新環境で十分にテストした後に、既存vRouter 5400からのVLAN disassociate/新規vRouter 5600へのVLAN associateで移行できる。
  • 何か問題があった場合は、VLANのassociate/disassociateのみでvRouter 5400の環境に戻すことができる。

デメリット

  • vRouter自身のIPアドレスやVRRPのVIPなどのIPアドレスは変更されてしまう。その結果、vRouterの対抗側VPN機器やオンプレミス側のNW構成の変更を伴うため、もしそういう対抗側環境が存在するならば影響範囲をクラウド側だけに留めることができない。
  • 新規にプロビジョニングしたvRouter 5600と既存vRouter 5400の並行稼働のための課金を考慮する必要がある。
  • 新規にプロビジョニングしたvRouter 5600に紐づける新規にVLANが必要になる（同一アカウントであれば、VLANを既にたくさん利用していて新規注文できないかもしれない？？？）
  • Firewall検証などにサーバーやストレージも別途必要になる。

3.2 既存のvRouter 5400を直接OS Reloadで移行する方法

vRouter5400 -> vRouter 5600にはOS reload（既存のサーバーに対して、OSを再導入する機能）で実施可能であり、その方法は以下の資料に記載があります。

メリット

  • IPアドレスは変更されない。
  • 既存サーバーを再利用するので、追加課金が最低限しか発生しない。
  • 既存サーバーを再利用するので、サーバーが新規注文できないといったリスクがない。
  • vRouter 5400のEOM(End of Market)までであれば、OS reloadをすることでvRouter 5600をvRouter 5400に戻すことが可能
  • vRouter 5400とvRouter 5600は、一応両者の間でVRRPによるHA構成を組むことができるので、本格的なテストをしたい時だけvRouter 5600に切り替え、問題が発生したらvRouter 5400に戻すといったことが可能

デメリット

  • サービス影響を最小限にするため、テストを十分に実施できない可能性がある。

vRouter 5400とvRouter 5600には多くの違いがあるので、事前の机上レビューだけで完全に網羅することは難しいと思われます。もしOS Reloadで移行するとしても、1) vRouter 5600での動作確認を別環境であらかじめ実施しておく、2)メンテナンス時間を十分に設け、テスト時間ともしもの時のための復旧時間を確保しておく、といった上で作業することが望ましいでしょう。

4. 移行前にやっておくべき作業

4.1 メンテナンス時間の確保

VLANのroute/bypassの変更やassociate/disassociate中はネットワーク断が発生するため、この間にVyatta経由でストレージアクセスするなどは避けるべきです。移行作業時間、テスト時間、もしもの時の復旧時間に備えて、十分なメンテナンス時間をあらかじめ確保しておきましょう。

4.2 事前バックアップ

  • vRouter 5400から vRouter 5600には、IBM CloudではOS reloadをすることでupgradeすることが可能です。その際には、設定ファイルは初期化されてしまうため、以下の手順などを利用してバックアップを取得しておきましょう。当たり前ですが、バックアップしたファイルは別サーバーなどに退避させておいて下さい。
構成ファイルのバックアップ方法
#configファイルのバックアップ
$ cp -pr /config/config.boot /config/config.boot_20170601

#tech-support用のファイルを収集する。/config/support/配下にファイルが作成される
$ show tech-support save
$ generate tech-support archive

4.3 Master/Backupノードの確認

どちらのノードがMASTER/BACKUPであるかの確認を行います。もしOS Reloadによる移行を実施する際にはBACKUP NODEから実施しましょう。

どちらのノードがMASTER/BACKUPであるかの確認
$ show vrrp
                                 RFC        Addr   Last        Sync
Interface         Group  State   Compliant  Owner  Transition  Group
---------         -----  -----   ---------  -----  ----------  -----
bond0             1      MASTER  yes        no     10s         vgroup1
bond0.1449        1      MASTER  no         no     10s         vgroup1
bond1             1      MASTER  yes        no     10s         vgroup1
bond1.1438        1      MASTER  no         no     10s         vgroup1

MASTER/BACKUPを切り替えるためには、MASTERノード側でreset vrrp masterコマンドを実行します。以下の例はgroup 1のものを切り替えた時の例ですが、group 2, 3も同様にコマンドを実行して切り替えることが可能です。

MASTER/BACKUPの切り替え
$ reset vrrp master interface bond0 group 1
vrrp group 1 on bond0 is in sync-group vgroup1
Forcing vyatta-bond1-1 to BACKUP...
Forcing vyatta-bond0-1 to BACKUP...
Forcing vyatta-bond0.1449-1 to BACKUP...
Forcing vyatta-bond1.1438-1 to BACKUP...

$ show vrrp
                                 RFC        Addr   Last        Sync
Interface         Group  State   Compliant  Owner  Transition  Group
---------         -----  -----   ---------  -----  ----------  -----
bond0             1      BACKUP  yes        no     18s         vgroup1
bond0.1449        1      BACKUP  no         no     18s         vgroup1
bond1             1      BACKUP  yes        no     18s         vgroup1
bond1.1438        1      BACKUP  no         no     18s         vgroup1

4.4 Preempt機能の無効化およびPriority値の確認

Preempt機能を無効化していると、1号機に障害が発生して2号機にTakeoverが発生した後に1号機が復旧しても、Priority値（数値が大きいほど優先度が高い）関係なしに2号機がMASTERであり続けます。
一方、Preempt機能を有効化していると、1号機に障害が発生して2号機にTakeoverが発生した後に1号機が復旧した際に、もし1号機のPrioirty値が高いと1号機に再度FailBackを行います。移行作業中にPriority値が高いサーバーに自動的に戻って欲しくないため、両ノードでPreempt機能は予め無効にしておくことを推奨します。
※そもそもPreempt機能は、VRRP構成を組む2台のVyattaに性能差がある際に、可能な限り性能値が高いノードで処理させるといったケースで有効ですが、どちらも同じ性能と機種を利用するのであればPreempt機能を利用する意味はほとんどないと思います。

PreeemptおよびPriorityの確認
$ show vrrp detail | grep Preempt
  Preempt:          disabled
  Preempt:          disabled
  Preempt:          disabled
  Preempt:          disabled

$ run show vrrp detail | grep Priority
  Priority:         254
  Priority:         254
  Priority:         254
  Priority:         254

4.5 Config-Sync機能の無効化の確認

# show system config-syncの構成から分かるように、デフォルトではnat, firewall, vpnの構成が自動的に同期されるように構成されています。もしvRouter 5600との混合環境を構成する際に、同期が試行されることによってシステムが不安定になる可能性があります。5400と5600の構成は異なるため、両者間で同期することは意味がありません。もしConfig-Syncを行うならば、両方のノードを5600にupgradeした後にするべきです。移行前には、両ノードでConfig-Syncは事前に無効化しておきましょう。

config-sync設定の削除
vyatta@vga01# delete system config-sync
vyatta@vga01# commit
vyatta@vga01# save

続きはこちらで！

12
7
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
12
7