У нас есть производственный экземпляр Oracle, работающий в подсети приложения, где несколько приложений обращаются к базе данных изнутри подсети (172.17.x.x). К сожалению, база данных очень старая, и все приложения подключаются к ней с использованием IP-адреса, а не DNS-имени. Я не знаю, какие приложения подключаются к базе данных. У нас есть требование переместить базу данных в другую подсеть в том же месте (10.52.x.x). Но приложение останется в другой подсети. Я хочу знать, каковы все механизмы для перемещения базы данных без воздействия на IP-адрес, предположим, 172.17.178.100. Пожалуйста, предложите
Я предложил использовать балансировщик нагрузки F5 для базы данных Oracle в первичной подсети с IP-адресом внешнего интерфейса (172.17.178.100) и сопоставить его с внутренним IP-адресом нового экземпляра базы данных вторичной подсети. Пожалуйста, предложите все альтернативные решения, так как у меня ограниченные знания в области сетей.
Перенести все приложения на использование DNS и задокументируйте свои выводы. Поскольку вы не знаете их всех, это будет процесс открытия.
Настройте новый IP-адрес на хосте и поместите его в DNS как служебный адрес, db.example.net или так. Сообщите всем возможным владельцам приложений проект переименования, и что ничего не получится, если не будет предпринято никаких действий. Установите крайний срок для идентификации и переименования каждой сопряженной системы.
Неизбежно что-то забудется. Выявите отстающих, зарегистрировав с помощью правил брандмауэра оставшиеся подключения к существующим 172.17.178.100 IP. Проведите небольшое расследование и отправьте владельцам все более срочные напоминания о том, что вы найдете.
Это была тяжелая работа. На самом деле переместить IP-адреса, вероятно, будет относительно легко. Следуйте контрольному списку, чтобы повторно настроить IP-адрес сервера и обновить DNS-имя.
Обновляя сетевые технологии этого десятилетия, настаивайте на том, чтобы поставщики поддерживали IPv6. Обильное глобальное адресное пространство предотвращает исчерпание или перекрытие подсетей.
Предложения @John Mahowald верны, особенно запись IP-адресов, которые подключаются к 172.17.178.100, чтобы определить, какие хосты все еще используют старый IP.
В зависимости от вашей ситуации может оказаться возможным туннелировать требуемый IP-адрес из старой подсети в новую. Это может быть полезно, если у вас не установлен крайний срок для завершения переноса сервера в новую подсеть 10.52.x.y, и у вас нет времени, чтобы заставить всех прекратить использовать старый IP-адрес до того, как вы сделаете переход. Описанный ниже метод может сделать 172.17.178.100 доступным для ваших пользователей, даже если сервер физически переместился в новую подсеть 10.52.x.y.
Я использовал этот метод в прошлом, чтобы сделать DNS-сервер доступным на двух IP-адресах одновременно: его новый IP-адрес в новом месте и его старый устаревший IP-адрес из отдельной подсети в другом месте. Затем я смог зарегистрировать удаленные хосты, которые все еще использовали старый IP-адрес, и перенести их на новый IP-адрес, не торопясь, чтобы избежать возможного простоя.
Необходимый ингредиент - это хозяин, который по-прежнему в устаревшей подсети, и которая должна оставаться в этой подсети, пока вы не завершите миграцию со старого IP-адреса на новый IP-адрес (или, лучше, новое DNS-имя). Я буду называть эту машину A, "конец A" и / или подсеть A.
Затем машина B живет в новой подсети (подсеть B) и имеет нормальный IP-адрес в подсети B. Машина B в конечном итоге получит старый IP-адрес, а трафик из старой подсети будет перенаправлен на машину B через туннель.
Когда я реализовал это (примерно на 3 месяца переходного периода), это было на FreeBSD, так что синтаксис здесь специфичен для BSD. Приведенная ниже установка может показаться немного корявой, но во многом это мое собственное переоценка. Всего 5 командных строк или меньше, которые можно поместить в сценарий и добавить в конфигурацию запуска при загрузке. Предполагая, что и старая подсеть, и новая подсеть находятся в одном центре обработки данных и используют безопасный путь маршрутизации, который не предоставляет ваш трафик общедоступному Интернету, последствия для безопасности должны быть довольно небольшими. Если трафик на 172.17.178.100 зашифрован или еще не зашифрован, он останется зашифрованным (или незашифрованным) с использованием этого метода. Я не эксперт по безопасности, но это похоже на исход «без изменений». Этот метод должен не использоваться для конфиденциального трафика, который туннелируется через незащищенную сеть (например, Интернет) на пути от машины A к машине B.
Для более безопасного и полного рассмотрения этой концепции см. Запись в Справочнике FreeBSD о VPN через IPSec, на котором основана эта идея.
# 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
Определите MAC-адрес подсети A машины A и опубликуйте запись прокси ARP, используя тот же MAC-адрес и старый IP-адрес 172.17.178.100:
# arp -s 172.17.178.100 78:2b:cb:3a:f6:93 pub
Затем мы создаем gif интерфейс и настроить gif туннель с локальным IP и удаленным IP (в указанном порядке). Обратите внимание, что это «внутренние» IP-адреса туннеля. Они не видны внешнему миру и используются только для маршрутизации трафика от машины A к машине B.
# ifconfig gif0 create
# ifconfig gif0 192.168.255.1 192.168.255.2
Вы должны выбрать IP-адреса RFC1939, которые не используются в вашем центре обработки данных. 192.168.255.1 - это внутренний IP-адрес конца A туннеля, а 192.168.255.2 - это внутренний IP-адрес конца B.
Далее мы определяем вне IP-адреса туннеля заканчиваются.
# ifconfig gif0 tunnel 172.17.178.105 10.52.100.200
Здесь 172.17.178.105 - это IP-адрес подсети A машины A. Вот почему я говорю, что для этого метода требуется система, которая будет «оставаться позади» в подсети A, в то время как IP-адрес вашего приложения 172.17.178.100 претерпевает миграцию в новое местоположение и подсеть B.
Последняя команда на компьютере A - направить трафик для устаревшего IP-адреса на удаленный (конец B). внутренний IP туннеля:
# route add 172.17.178.100 192.168.255.2
Теперь перейдем к конфигурации конца B. Не требуется ни проксирования ARP, ни специальной маршрутизации, поэтому для настройки требуется всего три команды вместо пяти:
# 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-адрес - локальный, а второй - удаленный. Итак, с конца B, локальный конец внутри IP-адрес 192.168.255.2, а удаленный внутренний IP-адрес - 192.168.255.1. Аналогичным образом, физические (внешние) IP-адреса: 10.52.100.200 на стороне B и 172.17.178.105 на конце A.
На конце 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
B конец 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 -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 вы сможете получить доступ к внутреннему IP-адресу конца A туннеля:
# 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
Осталось только предоставить старый IP 172.17.178.100 на машине B. Предположим, что интерфейс машины B - bge0.
# ifconfig bge0 add 172.17.178.100/32
Теперь с машины A (или любой другой машины) вы должны иметь возможность пинговать 172.17.178.100.
На машине 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
Если это не то, что вы предпочитаете, можно попросить сетевых инженеров вашего центра обработки данных предоставить вам транковый порт Ethernet. Для этого потребуется, чтобы к подсети A и подсети B можно было получить доступ через разные VLAN. Узнайте у своих сетевых инженеров. На машине B должен быть сетевой адаптер с поддержкой VLAN, а конфигурация сети должна быть изменена для настройки VLAN 10.52.x.x отдельно от VLAN 172.17.178.x. Обратной стороной этого является то, что это требует затрат для сетевых инженеров центра обработки данных, которые могут иметь или не иметь времени или желания помочь вам. OTOH, gif для метода туннелирования интерфейса требуется нет посторонняя помощь, за исключением разрешения оставить компьютер A в сети и подключиться к подсети A на время, необходимое вам для завершения миграции.
Свободные идеи: