Лучшая практика для изменения сайта на новый сервер&ip, включая дополнительный hdd без простоя? [закрыто]
У меня есть очень активный сайт, который мне нужно перевести на новый сервер. Основная часть задачи выполнена, но сейчас я нахожусь в финальной стадии, и, возможно, вы сможете помочь.
Этот сайт использует не только корневой жесткий диск, на котором хранятся данные сайта, но и данные пользователей, к которым постоянно осуществляется доступ на другом жестком диске сервера.
Данные сайта теперь полностью зеркалируются на копии моей панели управления на новом сервере - но не данные с массивного дополнительного диска, который непрактично зеркалировать из-за его огромного размера и постоянно меняющихся данных.
Вместо этого решением будет отключить дополнительный диск и физически перенести его на новый сервер во время запланированного 5-минутного простоя. Я переведу сайт в режим обслуживания на старом сервере на этот период.
База данных SQL также зеркалируется, но, конечно, базу данных SQL нужно будет скопировать в последний раз сразу после переключения. Я сделаю это в течение 5 минут запланированного простоя. Я смогу выполнить эту задачу в течение этих 5 минут.
48 часов прерывистой доступности во время распространения будут неприемлемы, поэтому просто сделать это не представляется возможным. Вместо этого мне нужно смягчить ситуацию во время распространения.
Вот следующие вопросы, которые нужно решить:
- отсутствие простоев даже из-за распространения. Одним из возможных вариантов может быть перенаправление запросов на старом сервере на IP нового сервера в течение 48 часов после смены DNS (сервера имен у регистратора). Я не уверен, как это сделать, но видел это, хотя я не уверен, какое из приведенных там решений будет лучшим в моей ситуации. (Имейте в виду, что я не могу просто перенаправить все запросы на порт 80, потому что мой сайт на https. Пробросить ли мне порт 443? Или одно из других предложенных решений, или другое решение, является лучшим вариантом?)
- sql миграция базы данных. Одна вещь, о которой я подумал, это изменить "localhost" в конфигурационном файле сайта на IP нового сервера. Я не уверен, что это сработает. Слышали ли вы об этом? Я видел, как вирусы, скомпрометировавшие конфигурационный файл, меняли localhost на свой IP вредоносной программы, так что, может быть, эта стратегия сработает в моем конкретном случае? (Кто бы мог подумать, что я буду учиться у пиратов!)
Проблемы, которые, как мне кажется, я решил, включают:
- физический перенос жесткого диска. Как было сказано выше, я физически перенесу его на новый сервер во время запланированного 5-минутного простоя, во время которого я в последний раз сделаю резервную копию и восстановление базы данных sql и изменю серверы имен.
- миграция данных. Это завершено, есть зеркальная копия данных на новом (живом) сервере.
Какова наилучшая стратегия для миграции высокоактивного сайта (с динамическими данными), который использует дополнительный (большой) диск, на новый сервер, сервер имен и IP?
Зависит от версии SQL Server и версии Windows Server 2012.
Далее по ссылке, которую вы сами разместили.
Но, насколько я могу судить, все версии Windows Server 2012 поддерживают все версии SQL Server 2016.
Полный список по ссылке выше:
. 121---438058-SQL Server Enterprise
Windows Server 2016 Datacenter
Windows Server 2016 Standard
Windows Server 2012 R2 Datacenter
Windows Server 2012 R2 Standard
Windows Server 2012 R2 Essentials
Windows Server 2012 R2 Foundation
Windows Server 2012 Datacenter
Windows Server 2012 Standard
Windows Server 2012 Essentials
Windows Server 2012 Foundation
SQL Server Standard
Windows Server 2016 Datacenter
Windows Server 2016 Standard
Windows Server 2012 R2 Datacenter
Windows Server 2012 R2 Standard
Windows Server 2012 R2 Essentials
Windows Server 2012 R2 Foundation
Windows Server 2012 Datacenter
Windows Server 2012 Standard
Windows Server 2012 Essentials
Windows Server 2012 Foundation
Windows 10 Home
Windows 10 Professional
Windows 10 Enterprise
Windows 8. 1
Windows 8.1 Pro
Windows 8. 1 Enterprise
Windows 8
Windows 8 Pro
Windows 8 Enterprise
SQL Server Web
Windows Server 2016 Datacenter
Windows Server 2016 Standard
Windows Server 2012 R2 Datacenter
Windows Server 2012 R2 Standard
Windows Server 2012 R2 Essentials
Windows Server 2012 R2 Foundation
Windows Server 2012 Datacenter
Windows Server 2012 Standard
Windows Server 2012 Essentials
Windows Server 2012 Foundation
Лучшей стратегией будет использование какой-либо синхронизации между серверами для перемещения данных, перемещение дисков - это всегда немного рискованный маневр, и обычно к нему прибегают только тогда, когда нет других вариантов. Обратите внимание, что если мы говорим о надлежащем серверном оборудовании, могут возникнуть некоторые проблемы с совместимостью дисков, например, RAID-контроллер Dell может не работать с дисками HP. Единственной причиной для перемещения диска в сценарии, не связанном с катастрофой, может быть перемещение, скажем, 10 ТБ через континент или что-то в этом роде, и тогда я также буду использовать отдельные носители для переноса или перемещать целые серверы вместо перемещения дисков между серверами.
Для копирования изменений между серверами я бы рекомендовал использовать что-то вроде rsync для выполнения основной части работы, а затем просто выключить службу веб-сервера на старом сервере, дать rsync закончить перенос изменений, а затем поднять новый сервер после изменения записей DNS.
Что касается задержки распространения; если я правильно вас понял, вас беспокоит задержка распространения DNS. Это связано с кэшированием, неавторитетные DNS серверы будут кэшировать ответы в соответствии со значением Time-To-Live записи. Обычно это что-то вроде 86400 секунд, или 24 часа. Эту проблему легко решить, заранее снизив значение TTL ваших записей DNS до чего-то низкого, например 300 секунд (5 минут), а затем подождав, пока пройдет больше времени, чем старое значение TTL. Таким образом, каждый DNS-сервер по всему миру будет иметь вашу новую запись только с 5-минутным TTL, что означает, что DNS не будет кэшировать вашу запись более 5 минут, что снизит вашу задержку распространения до абсолютного минимума.