Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 35
Конспектирую (с добавлениями):
1) Не держите почту и DNS у хостера
2) Бэкапьте почаще базу sql (если она есть) и сайт целиком
3) Не экономьте на хостере 3 копейки, рубль потеряете
4) Для переезда просто перетащите сайт и всяческие .htaccess'ы (если есть) и перелейте базу путем экспорта/импорта
5) Для завершения переезда меняете DNS-записи
6) Done!
1) Не держите почту и DNS у хостера
2) Бэкапьте почаще базу sql (если она есть) и сайт целиком
3) Не экономьте на хостере 3 копейки, рубль потеряете
4) Для переезда просто перетащите сайт и всяческие .htaccess'ы (если есть) и перелейте базу путем экспорта/импорта
5) Для завершения переезда меняете DNS-записи
6) Done!
К сожалению, ваш конспект рассказывает не то, о чем писал я. Как раз по такому конспекту делают те переезды, которые я и упоминал в начале, когда сайт недоступен в течении какого-то времени. Вы действительно вчитались в текст?
В каком месте моего конспекта присутствует недоступность? Ваш метод с удаленной базой не подойдет сайтам с мало-мальски серьёзной нагрузкой, будет не просто «замедления работы сайта» а всё просто встанет колом. Проще перевести базу в режим readonly на момент переноса.
Для реализации нормального гео-кластера с онлайн-репликацией баз нужно иметь тёмную оптику между ДЦ (или хотя бы выделенный канал на гарантированные 100, а лучше 1000 мбит), через Интернет такое не работает, увы. Но для мелких сайтов ваша задумка подойдет, да.
Для реализации нормального гео-кластера с онлайн-репликацией баз нужно иметь тёмную оптику между ДЦ (или хотя бы выделенный канал на гарантированные 100, а лучше 1000 мбит), через Интернет такое не работает, увы. Но для мелких сайтов ваша задумка подойдет, да.
еще раз «Также данная инструкция может быть неприменима при переезде высоконагрузочных и распределенных ресурсов, но не мне уже подсказывать администраторам таких ресурсов, как организовывать подобный переезд.». Я ж говорю — вы не вчитывались даже… Недоступность у вас будет на 4 и 5 пунктах, когда вы будете перетаскивать сайт (кстати как?).
Недоступность у вас будет на 4 и 5 пунктах, когда вы будете перетаскивать сайт (кстати как?).Мне проще, у нас применяется SAN, где и лежат все базы и всё остальное и своя оптика между ДЦ. ;)
А для ребят поэкономнее ответ на вопрос «как?» прост — как вам удобнее: scp, ftp, rsync, да хоть по e-mail :) копирование не прерывает сервис, а базу можно в readonly перевести, как я и сказал, можно сделать это в часы минимальной посещаемости.
Насчет пункта 5 вы также заблуждаетесь: заранее выставляем TTL для A-записей в 60 секунд, меняем А-запись, кто-то еще в течение минуты ходит по старому ip (а там сайт тоже доступен), кто-то уже по новому, через несколько минут все пользователи на новом ip, включаем базу read-write. Done!
все на много проще
А был неоднократным свидетелем, когда «на много проще» выливалось в недоступность сайта в течении суток или более, а админ сидел и кусал локти, не понимая, когда же у него заработает сайт.
я был участником не давних событий, большинство времени потерял на делегировании домена )
i.li.ru/i/s/1ROJbS.png
i.li.ru/i/s/1ROJbS.png
Про домен при переезде не забываем: habrahabr.ru/blogs/domains/91599/
Доме надо или держать у регистратора напрямую, или постоянно мониторить ЖИВ ЛИ ВАШ РЕСЕЛЛЕР
Доме надо или держать у регистратора напрямую, или постоянно мониторить ЖИВ ЛИ ВАШ РЕСЕЛЛЕР
Честно говоря, опять очень много воды, нет конкретики.
1)По поводу удаленного доступа к SQL — если хостер дает ssh, то удаленный доступ будет всегда с помощью туннеля. Если у хостера нет ssh — то лучше найти такого, где есть (почему — см. п.2)
2)Копирование данных. Копировать по ftp — вы умрете. Особенно если это какая-нибудь крупная cms с кеширование. Для примера у рабочего сайта на 1С-Битрикс около 30 тыс мелких файлов. Гораздо удобнее и быстрее — зайти по ssh, затарить домен и скопировать его сразу же на новый хостинг, без использования своего компьютера. У хостеров обычно каналы быстрее, чем домашний.
3)Изменение DNS-серверов. Вы путаете. 3-4 часа будет изменяться скорее DNS-запись, а при изменении DNS-серверов может потребоваться до нескольких суток, перед тем как везде будет отдаваться правильные серверы. Пруффлинки:
www.2domains.ru/faq/q.php?id=90#answers
host-solutions.ru/hosting-support/faq/232-dns.html
1)По поводу удаленного доступа к SQL — если хостер дает ssh, то удаленный доступ будет всегда с помощью туннеля. Если у хостера нет ssh — то лучше найти такого, где есть (почему — см. п.2)
2)Копирование данных. Копировать по ftp — вы умрете. Особенно если это какая-нибудь крупная cms с кеширование. Для примера у рабочего сайта на 1С-Битрикс около 30 тыс мелких файлов. Гораздо удобнее и быстрее — зайти по ssh, затарить домен и скопировать его сразу же на новый хостинг, без использования своего компьютера. У хостеров обычно каналы быстрее, чем домашний.
3)Изменение DNS-серверов. Вы путаете. 3-4 часа будет изменяться скорее DNS-запись, а при изменении DNS-серверов может потребоваться до нескольких суток, перед тем как везде будет отдаваться правильные серверы. Пруффлинки:
www.2domains.ru/faq/q.php?id=90#answers
host-solutions.ru/hosting-support/faq/232-dns.html
Согласен. Но далеко не все нормальные провайдеры предоставляют доступ к SSH, ничуть при этом не теряя в качестве.
По поводу ftp — не важно, каким образом, по простому ftp или sftp. Вытекает из возможности использования SSH и умения использовать консоль пользователем.
Насчет DNS — не знаю, почему вы считаете, что изменение dns-сервера в учетке по домену у регистратора будет происходить до нескольких суток. На деле это реально несколько часов, т.к. провайдеров, которые обновляют свои DNS раз в неделю, уже практически не осталось (я не встречал). Указание в справок «до трех суток» — это лишь подстраховка.
По поводу ftp — не важно, каким образом, по простому ftp или sftp. Вытекает из возможности использования SSH и умения использовать консоль пользователем.
Насчет DNS — не знаю, почему вы считаете, что изменение dns-сервера в учетке по домену у регистратора будет происходить до нескольких суток. На деле это реально несколько часов, т.к. провайдеров, которые обновляют свои DNS раз в неделю, уже практически не осталось (я не встречал). Указание в справок «до трех суток» — это лишь подстраховка.
На деле это реально несколько часов, т.к. провайдеров, которые обновляют свои DNS раз в неделю, уже практически не осталось (я не встречал).Народ, вы чего? Кто кого обновляет? Вы знакомы с принципами работы DNS? В частности с полем TTL в записи RR??
Вместо выкриков спокойно бы рассказали несведущим, в чем мы неправы.
Уже рассказывал, правда никто не вчитывается в текст :)
Расскажу подробнее:
В системе DNS есть различные типы записей: A, MX, PTR, etc., один из основополагающих типов — RR-записи (Resource Records, ресурсные записи), одним из полей которого является TTL (Time-To-Live, время жизни), которое говорит неавторитетным ДНС-серверам, сколько времени максимум можно хранить в кеше записи для данного домена. Минимальное время — 60 секунд, дефолтное в bind — 3600 секунд (1 час). Именно от значения этого поля зависит время, которое уйдет на смену ip-адреса у записи. Кроме того, поле TTL можно отдельно задавать для каждой записи внутри одной зоны (домена), пример для bind9:
время жизни для данной A-записи — 5 минут, т.е. если сменить эту запись, что через 5 минут весь интернет будет знать ваш новый ip
Расскажу подробнее:
В системе DNS есть различные типы записей: A, MX, PTR, etc., один из основополагающих типов — RR-записи (Resource Records, ресурсные записи), одним из полей которого является TTL (Time-To-Live, время жизни), которое говорит неавторитетным ДНС-серверам, сколько времени максимум можно хранить в кеше записи для данного домена. Минимальное время — 60 секунд, дефолтное в bind — 3600 секунд (1 час). Именно от значения этого поля зависит время, которое уйдет на смену ip-адреса у записи. Кроме того, поле TTL можно отдельно задавать для каждой записи внутри одной зоны (домена), пример для bind9:
123.example.com 5M IN A 123.123.123.123время жизни для данной A-записи — 5 минут, т.е. если сменить эту запись, что через 5 минут весь интернет будет знать ваш новый ip
Вы говорите про DNS-записи. А есть еще DNS-серверы, и там будет все меняться гораздо дольше.
вы смеётесь что ли? Давайте дам ещё краткую лекцию про авторитетные ДНС-сервера и рекурсию:
Эпиграф: «Чтобы понять рекурсию — нужно понять рекурсию»
Существует два типа DNS-серверов с точки зрения пользователя — Авторитетные и Рекурсивные.
Авторитетные — это те, которые содержат в себе информацию о зонах и записях внутри зон.
Рекурсивные — ничего в себе не содержат, а умеют только обращаться к Авторитетным за информацией о зонах и записях и хранить эту информацию в своем кеше некоторое время.
Когда пользователь набирает в браузере «www.example.com» то начинаются удивительные вещи: локальный системный резолвер смотрит на свой локальный кеш ДНС, и если не находит там нужной записи, идёт выше — к ДНС-серверу, прописанному в настройках системы. Этот ДНС-сервер смотрит свой локальный кеш и также не находит там нужной записи, вот беда… Но это не проблема — он ведь знает, что такое рекурсия! Он идет к корневому ДНС-серверу, отвечающему за зону .com и спрашивает у него:
— Скажи-ка брат, а кто у нас Авторитет на зоне example.com?
— Скажу, конечно — ns1.example.com
— Спасибо!
Далее путешествие нашего рекурсора продолжаются, он теперь спрашивает у Авторитетного ns1.example.com:
— Здравствуйте, Уважаемый! Не соблаговолите ли вы сообщить, какой ip-адрес у A-записи www.example.com?
— Говно-вопрос, ща, гляну в свои зоны… Вот, держи — IN A www.example.com 123.123.123.123 TTL=3600
— Спасибо!
Теперь наш отважный рекурсор возвращается к себе, кладет запись в кеш на 3600 секунд и отдает ее запросившему резолверу пользователя.
Пользователь наслаждается открывающимся сайтом.
Happy End!
P.S.: а по истечении 3600 секунд весь трудный путь резолвера повторяется…
Эпиграф: «Чтобы понять рекурсию — нужно понять рекурсию»
Существует два типа DNS-серверов с точки зрения пользователя — Авторитетные и Рекурсивные.
Авторитетные — это те, которые содержат в себе информацию о зонах и записях внутри зон.
Рекурсивные — ничего в себе не содержат, а умеют только обращаться к Авторитетным за информацией о зонах и записях и хранить эту информацию в своем кеше некоторое время.
Когда пользователь набирает в браузере «www.example.com» то начинаются удивительные вещи: локальный системный резолвер смотрит на свой локальный кеш ДНС, и если не находит там нужной записи, идёт выше — к ДНС-серверу, прописанному в настройках системы. Этот ДНС-сервер смотрит свой локальный кеш и также не находит там нужной записи, вот беда… Но это не проблема — он ведь знает, что такое рекурсия! Он идет к корневому ДНС-серверу, отвечающему за зону .com и спрашивает у него:
— Скажи-ка брат, а кто у нас Авторитет на зоне example.com?
— Скажу, конечно — ns1.example.com
— Спасибо!
Далее путешествие нашего рекурсора продолжаются, он теперь спрашивает у Авторитетного ns1.example.com:
— Здравствуйте, Уважаемый! Не соблаговолите ли вы сообщить, какой ip-адрес у A-записи www.example.com?
— Говно-вопрос, ща, гляну в свои зоны… Вот, держи — IN A www.example.com 123.123.123.123 TTL=3600
— Спасибо!
Теперь наш отважный рекурсор возвращается к себе, кладет запись в кеш на 3600 секунд и отдает ее запросившему резолверу пользователя.
Пользователь наслаждается открывающимся сайтом.
Happy End!
P.S.: а по истечении 3600 секунд весь трудный путь резолвера повторяется…
Так, а почему тогда некоторые пользователи и через несколько часов могут не видеть новый сайт?
1) TTL слишком большое
2) Не работает/плохо работает репликация master/slave у хостера ДНС, т.е. часть рекурсоров обратилась к ns1.example.com, который является мастером, на котором вносились изменения и у этих клиентов всё ОК, а часть к ns2.example.com, который является slave'ом и по причине кривизны рук админа (наиболее частая проблема — забывают изменить serial зоны) не получил свежую версию файла зоны, поэтому эта часть клиентов получает старый ip.
добавлю: терминология master/slave не имеет никакого смысла с точки зрения клиента, для него оба они — Авторитетные в одинаковой степени.
2) Не работает/плохо работает репликация master/slave у хостера ДНС, т.е. часть рекурсоров обратилась к ns1.example.com, который является мастером, на котором вносились изменения и у этих клиентов всё ОК, а часть к ns2.example.com, который является slave'ом и по причине кривизны рук админа (наиболее частая проблема — забывают изменить serial зоны) не получил свежую версию файла зоны, поэтому эта часть клиентов получает старый ip.
добавлю: терминология master/slave не имеет никакого смысла с точки зрения клиента, для него оба они — Авторитетные в одинаковой степени.
еще бывает «застревает» кеш локальных резолверов ОС, наиболее часто встречается в случае с Windows. Лечится так:
Но это уже не проблема системы ДНС, она работает чётко.
А в особо клинических случаях выясняется, что клиент когда-то «для надежности» добавил запись в hosts-файл, а потом забыл )
ipconfig /flushdns Но это уже не проблема системы ДНС, она работает чётко.
А в особо клинических случаях выясняется, что клиент когда-то «для надежности» добавил запись в hosts-файл, а потом забыл )
Ну так я как раз и говорил в разрезе несколько часов, учитывая самые затяжные случаи…
Если хостер не дает ssh — то лучше уходить от такого, вы лишаетесь:
1)sftp — передавать все данные в открытом виде не есть хорошо
2)установки и сборки необходимого по (например, тот же php-cgi себе собрать для каких-то целей)
3)создания собственных архивов сайта и баз по расписанию
А по поводу DNS — я в этом уверен, т.к. тесно связан с хостингом уже долгое время и вопросы от клиентов по поводу того, что их домен не виден в сети даже через сутки после делегирования приходят часто.
1)sftp — передавать все данные в открытом виде не есть хорошо
2)установки и сборки необходимого по (например, тот же php-cgi себе собрать для каких-то целей)
3)создания собственных архивов сайта и баз по расписанию
А по поводу DNS — я в этом уверен, т.к. тесно связан с хостингом уже долгое время и вопросы от клиентов по поводу того, что их домен не виден в сети даже через сутки после делегирования приходят часто.
Как я уже упоминал я с вами согласен. Но для приемлемого использования SSH и другх возможностей нужно хотя бы владеть основами администрирования. Врядли многие владельцы сайтов будут заморачиватся такими вещами. Лично мне ftp практически не нужен для хостинга, только при закидывании туда файлов и то редко. Все остальное можно делать через панель управления, почти все из них предоставляют удобные средства для управления файлами и даже распаковки архивов и т.п. Поверьте, далеко не все будут самостоятельно настраивать архивирование самостоятельно…
Ну и вообще — конкретика нужна профессионалам. А моя инструкция предназначена больше для начинающих администраторов (впрочем в жизни и опытные администраторы как-то не особо задумываются над этими вопросами).
1. Предложите сделать переезд новому хостеру.
2. PROFIT
2. PROFIT
А есть гарантия, что он сделает все как надо? Все перенесет, что вам нужно, не перенесет то, что не нужно? Лучше кмк взять бразды правления в свои пальцы, а не доверятся другим… Вполне достаточно, что они обеспечивают хостинг для сайта… Впрочем, может и есть смысл… Я лично не пробовал брать такую услугу, у меня нет доверия пока ни к одному хостеру.
Первый раз на своей практике столкнулся с «1 камень. Почта.» на новом хостинге. При обнаружении проблемы обратился в ТП. Поддержка, спустя сутки, предложила первый вариант сменить плекс на спанел, а спустя еще сутки воспользоваться услугами гугл.
Раньше, когда все работало, как то и не задумывался о почтовом сервисе хостера. Настроил и забыл.
Раньше, когда все работало, как то и не задумывался о почтовом сервисе хостера. Настроил и забыл.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Краткая инструкция по переезду сайта с одного хостера на другой