複数のアプリケーションがサブネット(172.17.x.x)内からデータベースにアクセスしているアプリケーションサブネットで実行されているOracle本番インスタンスがあります。残念ながら、データベースは非常に古く、すべてのアプリケーションがDNS名ではなくIPアドレスを使用して接続しています。データベースに接続しているすべてのアプリケーションが何であるかわかりません。データベースを同じ場所(10.52.x.x)内の別のサブネットに移動する必要があります。ただし、アプリケーションは他のサブネットに残ります。 172.17.178.100と仮定して、IPアドレスに影響を与えずにデータベースを移動するためのすべてのメカニズムを知りたいです。提案してください
フロントエンドIP(172.17.178.100)のプライマリサブネットで使用するOracleデータベース用のF5ロードバランサーを提案し、セカンダリサブネットの新しいデータベースインスタンスのバックエンドIPアドレスにマップします。私はネットワーキングに関して知識が限られているので、すべての代替ソリューションを提案してください。
DNSを使用するようにすべてのアプリケーションを移行し、調査結果を文書化します。それらのすべてを知っているわけではないので、これは発見プロセスになります。
ホストに新しい別のIPアドレスを構成し、それをサービスアドレスdb.example.net
などとしてDNSに配置します。可能なすべてのアプリケーション所有者に名前変更プロジェクトを通知します。アクションを実行しないと、動作しません。すべてのインターフェースシステムを識別して名前を変更する期限を設定します。
必然的に何かが忘れられます。既存の172.17.178.100
IPへの接続が残っているファイアウォールルールでログを記録して、遅延を特定します。これらについて調査を行い、見つけたものの所有者にますます緊急のリマインダーを送信します。
それは大変な作業でした。実際のIPの移動はおそらく比較的簡単です。チェックリストに従ってサーバーを再IPし、DNS名を更新します。
この10年間のネットワークテクノロジーに更新しながら、ベンダーがIPv6をサポートしていると主張します。十分なグローバルアドレス空間により、サブネットの不足や重複を防ぎます。
@John Mahowaldの提案は確かで、特に172.17.178.100に接続するIPをログに記録して、どのホストがまだ古いIPを使用しているかを判断します。
状況によっては、必要なIPを古いサブネットから新しいサブネットにトンネリングできる場合があります。これは、サーバーの新しい10.52.x.yサブネットへの移動を完了する期限があり、移動する前に古いIPの使用を全員に停止させる時間がない場合に役立ちます。以下で説明する手法により、サーバーが物理的に新しい10.52.x.yサブネットに移動した場合でも、ユーザーは172.17.178.100にアクセスできるようになります。
私は過去にこの手法を使用して、DNSサーバーを2つのIPで同時に使用できるようにしました。新しい場所にある新しいIPと、別の場所にある別のサブネットからの古いレガシーIPです。その後、古いIPを使用しているリモートホストをログに記録し、ダウンタイムを回避するためにRushを実行する必要なく、新しいIPを使用するようにホストを移行することができました。
必要な要素は、レガシーサブネット上にstillであり、古いIP番号から新しいIP(またはより適切には新しいDNS名)。そのマシンAを「Aエンド」および/またはサブネットAと呼びます。
次に、マシンBは新しいサブネット(サブネットB)に存在し、サブネットBに通常のIPアドレスを持ちます。マシンBは最終的に古いIPでプロビジョニングされ、古いサブネットからのトラフィックは、を介してマシンBに再ルーティングされます。トンネル。
これを実装したとき(約3か月の移行期間)、FreeBSD上にあったため、ここでの構文はBSD固有です。以下の設定は少し厄介に聞こえるかもしれませんが、それの多くは私自身の過剰な説明です。スクリプトに入れて起動時のスタートアップ構成に追加できるのは、わずか5コマンドライン以下です。古いサブネットと新しいサブネットの両方が同じデータセンターにあり、トラフィックをパブリックインターネットに公開しない安全なルーティングパスを使用していると仮定すると、セキュリティへの影響はかなり小さいはずです。 172.17.178.100へのトラフィックが暗号化されているか、まだ暗号化されていない場合、この方法を使用して暗号化されたまま(または暗号化されないまま)になります。私はセキュリティの専門家ではありませんが、それは「正味の変化なし」の結果のようです。このメソッドは、マシンAからマシンBに向かう途中で、安全でないネットワーク(インターネットなど)を介してトンネリングされるセンシティブトラフィックにはnot使用しないでください。
この概念のより安全で完全な扱いについては、このアイデアの基礎となっている VPN over IPSecに関するFreeBSDハンドブックのエントリ を参照してください。
# sysctl net.inet.ip.forwarding=1
# arp -s 172.17.178.100 78:2b:cb:3a:f6:93 pub
# ifconfig gif0 create
# ifconfig gif0 192.168.255.1 192.168.255.2
# ifconfig gif0 tunnel 172.17.178.105 10.52.100.200
# route add 172.17.178.100 192.168.255.2
それらを分解する:
インターフェイス間でパケットを転送するにはAエンドが必要になるため、正しいsysctl
設定が必要です。
# sysctl net.inet.ip.forwarding=1
次のもので永続化します:
# echo 'net.inet.ip.forwarding=1' >> /etc/sysctl.conf
マシンAのサブネットAのMACアドレスを特定し、同じMACアドレスと古いIP 172.17.178.100を使用してARPプロキシエントリを公開します。
# arp -s 172.17.178.100 78:2b:cb:3a:f6:93 pub
次に、gif
インターフェイスを作成し、ローカルIPとリモートIPを(この順序で)使用してgif
トンネルを構成します。これらはトンネルの「内部」IPであることに注意してください。これらは外部からは見えず、マシンAからマシンBにトラフィックをルーティングするためにのみ使用されます。
# ifconfig gif0 create
# ifconfig gif0 192.168.255.1 192.168.255.2
データセンターで使用されていないRFC1939IPアドレスを選択する必要があります。 192.168.255.1はトンネルのAエンドの内部IPで、192.168.255.2はBエンドの内部IPです。
次に、トンネルエンドのoutsideIPを定義します。
# ifconfig gif0 tunnel 172.17.178.105 10.52.100.200
ここで、172.17.178.105はマシンAのサブネットA IPです。そのため、この方法ではAサブネットに「遅れる」システムが必要であり、アプリケーションIP172.17.178.100は新しい場所とサブネットBに移行されます。
マシンAの最後のコマンドは、レガシーIPのトラフィックをリモート(Bエンド)内部トンネルIPにルーティングすることです。
# route add 172.17.178.100 192.168.255.2
それでは、Bエンド構成に移りましょう。 ARPプロキシは必要なく、特別なルーティングも必要ないため、セットアップは5つではなく3つのコマンドのみです。
# ifconfig gif0 create
# ifconfig gif0 192.168.255.2 192.168.255.1
# ifconfig gif0 tunnel 10.52.100.200 172.17.178.105
IP番号がA側で使用したものと逆になっていることに注意してください。最初のIPはローカルIPで、2番目のIPはリモートIPです。したがって、Bエンドから、ローカルエンドinsideIPは192.168.255.2であり、リモートエンド内部IPは192.168.255.1です。同様に、物理(外部)IPは、B側で10.52.100.200、A側で172.17.178.105です。
A側では、次のように表示されます。
# ifconfig gif0
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
options=80000<LINKSTATE>
tunnel inet 172.17.178.105 --> 10.52.100.200
inet6 fe80::7a2b:cbff:fe3a:f693%gif0 prefixlen 64 scopeid 0x8
inet 192.168.255.1 --> 192.168.255.2 netmask 0xffff0000
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
groups: gif
曲がった所 gif0
インターフェースは同じですが、IPが逆になっています。
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
options=80000<LINKSTATE>
tunnel inet 10.52.100.200 --> 172.17.178.105
inet 192.168.255.2 --> 192.168.255.1 netmask 0xffff0000
groups: gif
Aから、リモートトンネルエンドポイントの内部IPにpingできるはずです。
# ping -c3 192.168.255.2
PING 192.168.255.2 (192.168.255.2): 56 data bytes
64 bytes from 192.168.255.2: icmp_seq=0 ttl=64 time=0.348 ms
64 bytes from 192.168.255.2: icmp_seq=1 ttl=64 time=0.394 ms
64 bytes from 192.168.255.2: icmp_seq=2 ttl=64 time=0.400 ms
--- 192.168.255.2 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.348/0.381/0.400/0.023 ms
同様に、Bからは、トンネルのA端の内部IPに到達できるはずです。
# ping -c3 192.168.255.1
PING 192.168.255.1 (192.168.255.1): 56 data bytes
64 bytes from 192.168.255.1: icmp_seq=0 ttl=64 time=0.342 ms
64 bytes from 192.168.255.1: icmp_seq=1 ttl=64 time=0.410 ms
64 bytes from 192.168.255.1: icmp_seq=2 ttl=64 time=0.383 ms
--- 192.168.255.1 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.342/0.378/0.410/0.028 ms
残っているのは、マシンBに古いIP 172.17.178.100をプロビジョニングすることだけです。マシンBのインターフェイスがbge0であると仮定します。
# ifconfig bge0 add 172.17.178.100/32
これで、マシンA(または実際には任意のマシン)から、172.17.178.100にpingを実行できるはずです。
マシンAの場合:
sysctl net.inet.ip.forwarding=1
# substitute Machine A's MAC address here:
arp -s 172.17.178.100 xx:xx:xx:xx:xx:xx pub
ifconfig gif0 create
ifconfig gif0 192.168.255.1 192.168.255.2
ifconfig gif0 tunnel 172.17.178.105 10.52.100.200
route add 172.17.178.100 192.168.255.2
マシンBの場合:
ifconfig gif0 create
ifconfig gif0 192.168.255.2 192.168.255.1
ifconfig gif0 tunnel 10.52.100.200 172.17.178.105
ifconfig bge0 add 172.17.178.100/32
上記が希望しない場合は、データセンターのネットワークエンジニアに トランクイーサネットポート を提供するように依頼することができます。これには、サブネットAとサブネットBが異なるVLANを介してアクセスできる必要があります。ネットワークエンジニアに問い合わせて確認してください。マシンBにはVLAN対応のネットワークアダプターが必要であり、ネットワーク構成を調整して10.52.xx VLAN 172.17.178.xVLANとは別に構成する必要があります。これは、データセンターのネットワークエンジニアにコストを課しているため、支援する時間や傾向がない場合とない場合があります。OTOH、gif
インターフェイストンネリングメソッドにはno外部からの支援。ただし、移行を完了するまでの時間、マシンAをオンラインのままにしてサブネットAに接続する許可は除きます。
ゆるいアイデア: