Сохраните IP-адреса при миграции на новую специализированную услугу хостинга

IP-адреса НЕ переданы, им присваивают. В блоках по крайней мере 4 096, которые не являются расщепляемыми.

Вы хотите свое собственное?

• Станьте членом ЗРЕЛЫХ или Вашего локального реестра (оплата его)
• Получите блок и AS (Автономная система).

Готово.

Иначе извините - адрес IP является частью AS присвоенный блок, и в конце дня это не является расщепляемым.

Если Вы придерживаетесь того же поставщика, в некоторых случаях они могут повторно присвоить им новому сервису, но нет никаких гарантий, и они могут заряжать Вас некоторая серьезная монета, чтобы заставить его произойти.

Если Вы идете с новым поставщиком, Вы не можете сохранить дюйм/с (если они не присвоены Вам, которые я собираюсь рискнуть и сказать, что они не).

Но это не должна быть проблема. Если Вы сделали свое проектирование сети правильно, изменение нумерации не является болезненным, просто требуется определенное внимание к деталям. Конечно, если Ваше проектирование сети является завтраком собаки, Вы находитесь в для мира боли, но можно использовать это в качестве полезного опыта в следующий раз. Отдельные моменты для замечания включают:

• Сохраните центральный реестр IP-адреса, как Вы был бы любой другой актив под Вашим управлением.
• Используйте DNS для всего.
• Используйте сервис CNAMEs для всего, что Вы можете.
• Не делайте hardcode IP-адресов нигде, Вы не имеете к; где угодно Вы действительно имеете к (кровавые брандмауэры), записываете в своем реестре IP-адреса, где это - hardcoded, почему это было сделано, и ссылка на документацию относительно того, как изменить его.

Изменение нумерации было бы значительно легче также, если бы некоторые [ругательство, удаленное] [ругательство, удаленное] [ругательство, удаленное] [ругательство, удаленное] [ругательство, удаленное] [ругательство, удаленное] кэширующиеся сопоставители DNS, не переопределяли Ваши значения TTL DNS. Учитывая, что нет абсолютно ничего, что можно делать с этим, у Вас просто должен быть план работать вокруг этого.

Во-первых, сделайте правильную вещь с DNS TTLs так, чтобы большинство хорошего поведения не получало удар. Отбросьте свой TTLs к чему-то хорошему и маленькому (как 5 минут) по крайней мере дважды текущий TTL перед cutover (почему дважды текущий TTL? Тот путь, если Вы делаете это неправильно, можно заметить вовремя и зафиксировать его).

Удостоверьтесь, что контракт на Вашем старом сервере перекрывает Вашу cutover дату, по крайней мере, на месяц. Когда Вы cutover на новый сайт, вставьте некоторые правила NAT о своем старом сервере для перенаправления трафика к новому серверу. Только сделайте это для выбранных портов (если Вы сделаете целую машину, то Вы заблокируете от своей способности войти в нее позже, и Вы не хотите платить за весь трафик мусора - сканирования портов и т.п. - которые являются белым шумом Ваших транспортных графиков). Следите за своими журналами для соединений от Вашего старого IP-адреса на новом сервере - когда они ни до чего не спали, затем мир забыл Ваш старый IP-адрес, и можно отбросить правила NAT о старом сервере и списать его.