Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 92
прочитал, по возможности понимая
1. для каких объемов это актуально?
2. как это спасет от того, что при чтении одного куска данных (одного файла, всех файлов отдельно от БД) не менялись другие, БД например?
дайте ссылку, не насилуйте уставший мозг
на русскую желательно
my english далеко не fluent
1. для каких объемов это актуально?
2. как это спасет от того, что при чтении одного куска данных (одного файла, всех файлов отдельно от БД) не менялись другие, БД например?
дайте ссылку, не насилуйте уставший мозг
на русскую желательно
my english далеко не fluent
вы получаете консистентную копию файловой системы на произвольный момент.
(что не означает консистентность скажем базы mysql, т.к. в этот момент она могла какие-то таблицы уже обновить, а какие-то нет).
но если вы можете на этот момент раз в сутки остановить сервисы, получить снапшот, заново запустить сервисы — получите и минимальный простой и консистентную копию.
(что не означает консистентность скажем базы mysql, т.к. в этот момент она могла какие-то таблицы уже обновить, а какие-то нет).
но если вы можете на этот момент раз в сутки остановить сервисы, получить снапшот, заново запустить сервисы — получите и минимальный простой и консистентную копию.
добавлю, что бакапы баз данных нужно делать другими средствами, например репликация
>что не означает консистентность скажем базы mysql, т.к. в этот момент она могла какие-то таблицы уже обновить, а какие-то нет
Базы не надо как файлы воспринимать. У топовых из них есть механизмы синхронизации, это конкретно касается клиент-серверных баз. Что в свою очередь позволяет хранить актуальную копию или копии на других серверах.
Причём после настройки обязанность за это будет лежать на самих серверах базы. То есть нужно просто прочитать книжки по той клиент-серверной базе которой пользуешься и всё настроить согласно инструкции.
Тогда в случае падения части системы компьютеров, пусть даже и расположенной в разных концах света, база не пострадает.
Базы не надо как файлы воспринимать. У топовых из них есть механизмы синхронизации, это конкретно касается клиент-серверных баз. Что в свою очередь позволяет хранить актуальную копию или копии на других серверах.
Причём после настройки обязанность за это будет лежать на самих серверах базы. То есть нужно просто прочитать книжки по той клиент-серверной базе которой пользуешься и всё настроить согласно инструкции.
Тогда в случае падения части системы компьютеров, пусть даже и расположенной в разных концах света, база не пострадает.
Это работает независимо от объема.
Механизм, если совсем примитивно, такой — доступ к состоянию данных на ФС ограничивается чтением. А вся запись идёт в другое место.
Таким образом, есть одновременно две копии данных — одна актуальная, а одна — неизменяемый снимок.
Механизм, если совсем примитивно, такой — доступ к состоянию данных на ФС ограничивается чтением. А вся запись идёт в другое место.
Таким образом, есть одновременно две копии данных — одна актуальная, а одна — неизменяемый снимок.
где-то год назад слышал, что такой снепшот жутко тормозит запущенный мускул, причем иногда с отваливанием последнего.
вы его используете в рабочем порядке?
вы его используете в рабочем порядке?
Давайте уже про iPad чтоли…
возникла мысль как переключаться без лага
Есть А — основной сервер
Есть В — резервный
поднимаются 2 DNS на А и на В соответственно
при этом DNS, который на А, указывает на себя, и второй соответственно на себя
у не уверен, что нормально пройдет делегирование, но если пройдет, то в случае аварии второй DNS сразу укажет новый адрес
осталось только настройки ns-ов исключить из синхронизации
Есть А — основной сервер
Есть В — резервный
поднимаются 2 DNS на А и на В соответственно
при этом DNS, который на А, указывает на себя, и второй соответственно на себя
у не уверен, что нормально пройдет делегирование, но если пройдет, то в случае аварии второй DNS сразу укажет новый адрес
осталось только настройки ns-ов исключить из синхронизации
делегирование не пройдет.
но никто не мешает вам осуществить переключение DNS серверов домена во Whois, в случае аварии — смена днс займет несколько часов (может до 2-3 дней) — при этом клиенты, которые не успели обновить днс не будут иметь возможности получить доступ к сайту.
это тот самый вариант холодного бекапа ниже.
варианты:
иметь две А записи на узел. пример
# host mail.ru
mail.ru has address 217.69.128.45
mail.ru has address 217.69.128.41
mail.ru has address 217.69.128.42
mail.ru has address 217.69.128.43
mail.ru has address 217.69.128.44
mail.ru mail is handled by 10 mxs.mail.ru.
таким образом обращения к разным серверам будут чередоваться (это, подразумевает наличии двух более-менее равноценных серверов). Здесь главный минус — обеспечение синхронизации двух серверов, со всем спектром проблем и тем, что если синхронизация проходит раз в 2 минуты, то после апдейта информации — она только через 2 минуты появится на сайте.
самый простой способ, как отмечается ниже — холодный резерв.
но никто не мешает вам осуществить переключение DNS серверов домена во Whois, в случае аварии — смена днс займет несколько часов (может до 2-3 дней) — при этом клиенты, которые не успели обновить днс не будут иметь возможности получить доступ к сайту.
это тот самый вариант холодного бекапа ниже.
варианты:
иметь две А записи на узел. пример
# host mail.ru
mail.ru has address 217.69.128.45
mail.ru has address 217.69.128.41
mail.ru has address 217.69.128.42
mail.ru has address 217.69.128.43
mail.ru has address 217.69.128.44
mail.ru mail is handled by 10 mxs.mail.ru.
таким образом обращения к разным серверам будут чередоваться (это, подразумевает наличии двух более-менее равноценных серверов). Здесь главный минус — обеспечение синхронизации двух серверов, со всем спектром проблем и тем, что если синхронизация проходит раз в 2 минуты, то после апдейта информации — она только через 2 минуты появится на сайте.
самый простой способ, как отмечается ниже — холодный резерв.
интересными терминами оперируете: «переключение DNS серверов домена во Whois» )
Длительность смены DNS-записей зависит исключительно от значения TTL у записи (А-записи в данном случае). Умолчальное значение обычно равно 3600 секундам, минимально возможное 60 секунд. Т.е. при желании только средствами DNS можно сократить downtime до нескольких минут (для этого, само собой, должен быть резервный сервер на другой площадке).
А ваш пример с mail.ru — это типичный DNS Round Robin, и количество серверов не ограничено двумя.
Длительность смены DNS-записей зависит исключительно от значения TTL у записи (А-записи в данном случае). Умолчальное значение обычно равно 3600 секундам, минимально возможное 60 секунд. Т.е. при желании только средствами DNS можно сократить downtime до нескольких минут (для этого, само собой, должен быть резервный сервер на другой площадке).
А ваш пример с mail.ru — это типичный DNS Round Robin, и количество серверов не ограничено двумя.
Есть три пути, ИМХО:
1) Дорогой, но очень надежный:
HA кластер из всех элементов системы на разных площадках. Минимальный downtime (в идеале вообще отсутствует), но стоит много денег (полное дублирование серверов и каналов)
2) Достаточно надежный, подешевле, чем 1):
Вторая площадка в «холодном» резерве с периодической репликацией данных и настроек (тот же бекап, другими словами)
3) Дешевый, если не сказать — бесплатный:
Ничего не делать, надеяться на «всё будет нормально, хостер надёжный»
1) Дорогой, но очень надежный:
HA кластер из всех элементов системы на разных площадках. Минимальный downtime (в идеале вообще отсутствует), но стоит много денег (полное дублирование серверов и каналов)
2) Достаточно надежный, подешевле, чем 1):
Вторая площадка в «холодном» резерве с периодической репликацией данных и настроек (тот же бекап, другими словами)
3) Дешевый, если не сказать — бесплатный:
Ничего не делать, надеяться на «всё будет нормально, хостер надёжный»
«Пусть оно стоит в штатах.»
Очень медленно открываются сайты.
«Может, там и лучше. Но чтобы там было 100% надежно — не думаю. Проблемы в случае аварий или подстав у вас будут бОльшего калибра, чем в этой стране.»
Не будут. Я не видел там ни разу, чтобы компании так срались. Т.е. ни разу.
Я не видел ни разу, чтобы компания, заблокировавшая доступ, затем его давала и делала это в качестве своего личного достижения.
Я не видел еще ни разу, чтобы такое компании спускалось с рук и на полном серьезе часть пользователей говорила о такой компании хорошие вещи.
Вообще ситуация с макхостом-оверсаном иллюстрирует любимое развлечение российских пиарщиков: пиар вместо дела и размытая ответственность. Никто ни за что не отвечает: никто не виноват. В неприлично демократических странах на это есть статья: ограничение свободы информации. Самые маленькие штрафы начинаются от 2000 евро.
Очень медленно открываются сайты.
«Может, там и лучше. Но чтобы там было 100% надежно — не думаю. Проблемы в случае аварий или подстав у вас будут бОльшего калибра, чем в этой стране.»
Не будут. Я не видел там ни разу, чтобы компании так срались. Т.е. ни разу.
Я не видел ни разу, чтобы компания, заблокировавшая доступ, затем его давала и делала это в качестве своего личного достижения.
Я не видел еще ни разу, чтобы такое компании спускалось с рук и на полном серьезе часть пользователей говорила о такой компании хорошие вещи.
Вообще ситуация с макхостом-оверсаном иллюстрирует любимое развлечение российских пиарщиков: пиар вместо дела и размытая ответственность. Никто ни за что не отвечает: никто не виноват. В неприлично демократических странах на это есть статья: ограничение свободы информации. Самые маленькие штрафы начинаются от 2000 евро.
""«Я не видел ни разу, чтобы компания, заблокировавшая доступ, затем его давала и делала это в качестве своего личного достижения.»"" —
не так давно очень похожая ситуация была с хостером проекта gentoo-potrage.com.
Товарищ описывал буквально следующее:
«Все полегло, хостер прячется втоой день. Иду в билдинг датацентра, там мне его владельцы объясняют — эти казлы (хостер-арендатор) не заплатили нам кучу бабла и хотели унести свои шкафы на соседнюю авеню. Мы им не дали и теперь разбирательство будет идти сколько-то месяцев. Можем пустить Вас в машзал, чтобы Вы сбэкапили свои сервера, но если Вы знаете партнамберы своих ящиков.» Партнамберы были у где-то у хостера, а тот мазался и прятался.
Товарищ всё это описывал в красках на пятый день лежания. Рвал на себе волосы и проклинал жадного хостера, который до самого конца говорил «всё будет Окей!».
Бэкапы у него были там же, так что потом всё комьюнити собирало по частям у кого что было.
Это так, к слову об Америке.
не так давно очень похожая ситуация была с хостером проекта gentoo-potrage.com.
Товарищ описывал буквально следующее:
«Все полегло, хостер прячется втоой день. Иду в билдинг датацентра, там мне его владельцы объясняют — эти казлы (хостер-арендатор) не заплатили нам кучу бабла и хотели унести свои шкафы на соседнюю авеню. Мы им не дали и теперь разбирательство будет идти сколько-то месяцев. Можем пустить Вас в машзал, чтобы Вы сбэкапили свои сервера, но если Вы знаете партнамберы своих ящиков.» Партнамберы были у где-то у хостера, а тот мазался и прятался.
Товарищ всё это описывал в красках на пятый день лежания. Рвал на себе волосы и проклинал жадного хостера, который до самого конца говорил «всё будет Окей!».
Бэкапы у него были там же, так что потом всё комьюнити собирало по частям у кого что было.
Это так, к слову об Америке.
проблема в том, что если немецкий хостер сдуется — клиентам из России получится только бессильно изливать злобу в блогах. Даже не понятно будет кому звонить и куда ехать. А про статью — это будет решать местный суд, и не по заявлению физлиц из других государств.
Мыши кололись и плакали, но продолжали жрать кактус
недавно настраивали нечто подобное.
файлы льём по крону rsync'ом, раз в 12 часов — репликация MySQL.
С NSами пока что автоматически ничего не придумали, но уже есть наработки.
Куда? Всем нам известные немцы. Сервера у них мощные, диски — большие. Самое то.
файлы льём по крону rsync'ом, раз в 12 часов — репликация MySQL.
С NSами пока что автоматически ничего не придумали, но уже есть наработки.
Куда? Всем нам известные немцы. Сервера у них мощные, диски — большие. Самое то.
почти такая схема реализована у нас.
В России находится FT кластер VMWare.
В буржуиндии куда:
в реалтайме реплицируются данные с mysql
раз в сутки rsync-аются файлы и svn up-ятся скрипты и проекты.
В случае падения FT кластера, LB NS сервера автоматически меняют зону на вторичные ресурсы.
Система работaет как часы (тьфу-тьфу-тьфу) в силу распределенности ресурсов (FT кластер на 3 площадках, 6 NS)
В России находится FT кластер VMWare.
В буржуиндии куда:
в реалтайме реплицируются данные с mysql
раз в сутки rsync-аются файлы и svn up-ятся скрипты и проекты.
В случае падения FT кластера, LB NS сервера автоматически меняют зону на вторичные ресурсы.
Система работaет как часы (тьфу-тьфу-тьфу) в силу распределенности ресурсов (FT кластер на 3 площадках, 6 NS)
А можно вопрос — почему в качестве бекапа всегда рассматривается зарубежная площадка, а не отечественная в другом ДЦ? Дешевле?
Надежнее, грамотно поддерживаемее, пожароустойчивее и ментозащищеннее
термин «ментозащищеннее» порадовал.
но вы правы.
я добавлю еще, что чаще всего зарубежная площадка дешевле или мощнее, но за те же деньги.
мы уже два года как уехали из России, сначала на Украину, теперь как раз едем к «тем самым немцам». Переезжаем не столько из-за надежности (пока все хорошо работает), а из-за увеличившейся нагрузки.
но вы правы.
я добавлю еще, что чаще всего зарубежная площадка дешевле или мощнее, но за те же деньги.
мы уже два года как уехали из России, сначала на Украину, теперь как раз едем к «тем самым немцам». Переезжаем не столько из-за надежности (пока все хорошо работает), а из-за увеличившейся нагрузки.
Может, там и лучше. Но чтобы там было 100% надежно — не думаю. Проблемы в случае аварий или подстав у вас будут бОльшего калибра, чем в этой стране.
Аргументируете?
А то как-то не очень убедительно смотрится. Тем более, что это самый короткий раздел в посте.
поддерживаю
примеры из личного опыта и сравнение с русскими хостерами
p.s. сам пользуюсь тремя буржуйскими хостингами несколько лет, проблем не было
примеры из личного опыта и сравнение с русскими хостерами
p.s. сам пользуюсь тремя буржуйскими хостингами несколько лет, проблем не было
не смогу. как выразился Лебедев, кожно-жопные ощущения
вывезти сервер и договориться на родном языке и ментальности вряд ли выйдет
вывезти сервер и договориться на родном языке и ментальности вряд ли выйдет
Работаю в саппорте компании, разрабатывающей софт для нужд хостинга.
Не то чтобы очень часто, но регулярно бывает что звонит кто-то и кричит, что его хостер обанкротился (как-то раз было «директора посадили»), доступа до серверов нет, по телефонам никто не отвечает… На нас выходят только потому, что на сервере стояла наша панель, надеются что мы иди данные можем помочь забрать, или на хостера выйти.
Не всё так замечательно в буржуинии, очень по-разному все бывает.
Не то чтобы очень часто, но регулярно бывает что звонит кто-то и кричит, что его хостер обанкротился (как-то раз было «директора посадили»), доступа до серверов нет, по телефонам никто не отвечает… На нас выходят только потому, что на сервере стояла наша панель, надеются что мы иди данные можем помочь забрать, или на хостера выйти.
Не всё так замечательно в буржуинии, очень по-разному все бывает.
Не знаю, насколько в тему, но был такой случай — у меня был сайт ориентированный на буржуйскую публику, и хостинг в Штатах. Когда лет 10 назад начался кипиш с бомбежкой штатами Югославии, я решил повесить на сайте призыв «Позвоните вашему конгрессмену» (к слову на многих американских сайтах видел эти баннеры и призызвы разместить их у себя). В итоге через пару часов получил от хостера письмо, что мой сайт потребляет слишком много ресурсов и они его скоро отключают. На вопрос, почему именно сейчас, а не пару месяцев назад, когда был всплеск посещаемости раза в три в связи с праздниками, ничего вразумительного не ответили. Немного подумав, сопоставив причины и следствие, я убрал баннер, и волшебным образом нагрузка упала до приемлемой величины.
Это недокументированная функция демократии.
У меня приятель в Нью-Йорке работал. Во время бомбежек его родной Югославии, он был среди выступающих и протестующих у здания ООН.
Через 2 недели его выгнали с работы, и с тех пор брали на работу, проходило 2 недели, и потом история с увольнением повторялась. Пришлось из Штатов уехать
У меня приятель в Нью-Йорке работал. Во время бомбежек его родной Югославии, он был среди выступающих и протестующих у здания ООН.
Через 2 недели его выгнали с работы, и с тех пор брали на работу, проходило 2 недели, и потом история с увольнением повторялась. Пришлось из Штатов уехать
На Windows server это делается довольно просто: между двумя серверами в разных странах поднимается VPN, репликация баз SQL Server, а для файлов — синхронизация даже какой-нибудь простой утилитой а-ля FreeFileSync.
В случае аварии, нужно только переписать все IP адреса на резервный сервер
На линуксе, наверное, тоже не проблема.
В случае аварии, нужно только переписать все IP адреса на резервный сервер
На линуксе, наверное, тоже не проблема.
Вариант Cluster — подходит идеально. По сути, он стоит не на много дороже. Самое главное что бы master и slave сервера находились в разных ДатаЦентрах.
Но, серьёзный ресурс кластер не потянет.
Но, серьёзный ресурс кластер не потянет.
Поясните последнюю фразу, она содержит внутреннее противоречие.
Кластер — это все таки шаред хостинг, нету таких хостеров которые захотят держать у себя грузилку, его сразу выгонят на ВПС или дедик
вы точно понимаете, о чём говорите? Начните с en.wikipedia.org/wiki/High-availability_cluster
что вы курите????
На последней фразе подавился.
файлы — синхронизируются через glusterfs, на крайняк — rsync
бд лежит на отдельном разделе и в ней настроена репликация средствами бд
про dns написали выше
никакой проблемы тут нет
бд лежит на отдельном разделе и в ней настроена репликация средствами бд
про dns написали выше
никакой проблемы тут нет
Перевод NS все же плох из-за кеширования записей.
RoundRobin DNS тоже не слишком хорош. Поправьте если ошибаюсь, но в RR часть запросов будет все же приходить на мертвый сервер.
Самым лучшим вариантом мне кажется наличие автономной системы (АС). Но это уже решение на уровне самого хостера.
Имея блок провайдеро-независимых адресов и две фермы в разных ДЦ можно очень быстро и прозрачно для клиента переключать фермы в случае падения одного из ДЦ.
На вопрос репликации и прочего — раздавать хосты при помощи VPS. В самом страшном случае — одна VPS на весь сервер, оверхед незначиельный. Xen (в свежей версии 4.0) и VMWare точно имеют решения по поддержанию HA-кластеров.
RoundRobin DNS тоже не слишком хорош. Поправьте если ошибаюсь, но в RR часть запросов будет все же приходить на мертвый сервер.
Самым лучшим вариантом мне кажется наличие автономной системы (АС). Но это уже решение на уровне самого хостера.
Имея блок провайдеро-независимых адресов и две фермы в разных ДЦ можно очень быстро и прозрачно для клиента переключать фермы в случае падения одного из ДЦ.
На вопрос репликации и прочего — раздавать хосты при помощи VPS. В самом страшном случае — одна VPS на весь сервер, оверхед незначиельный. Xen (в свежей версии 4.0) и VMWare точно имеют решения по поддержанию HA-кластеров.
Вроде как есть сервисы, предлагающие быстрое обновление dns.
Скажем, www.zerigo.com/managed-dns
Сам я с ними не работал, но обещают TTL записи начиная от одной минуты…
Скажем, www.zerigo.com/managed-dns
Сам я с ними не работал, но обещают TTL записи начиная от одной минуты…
>в RR часть запросов будет все же приходить на мертвый сервер.
Да, так и есть. Поэтому обычно в RR запускают побольше серверов, например штук 5. Чем их больше, тем меньшее количество запросов придёт на мертвый сервер, кроме того можно быстро исключать из RR этот мёртвый сервер, выставив маленький TTL на А-записи.
А свою AS держать дорого, 2300 евро в год для Very Small LIR, но можно у какого-нибудь LIR'а купить PI-блок, это гораздо дешевле (цена зависит от LIR'а).
Да, так и есть. Поэтому обычно в RR запускают побольше серверов, например штук 5. Чем их больше, тем меньшее количество запросов придёт на мертвый сервер, кроме того можно быстро исключать из RR этот мёртвый сервер, выставив маленький TTL на А-записи.
А свою AS держать дорого, 2300 евро в год для Very Small LIR, но можно у какого-нибудь LIR'а купить PI-блок, это гораздо дешевле (цена зависит от LIR'а).
Это да. Но у нормального хостера AS как правило своя есть. Так что, вопрос лишь в том, почему этот подход не используется ;)
Отчего же, вполне себе используется. У нашей организации, например, два собственных географически разнесенных ДЦ и собственная AS для личных нужд, многие сервисы так и переключаются, downtime у bgb практически отсутствует. Дорого это всё для большинства просто.
*bgp, опечатка.
Но нужно учитывать, что отказоустойчивость на layer4 это только верхушка огромного айсберга кластеризации, гораздо важнее и сложнее обеспечить отказоустойчивость на уровне серверов приложений и баз данных. Но еще раз подчеркну, GEO-кластер далеко не всем подходит в силу высокой стоимости развертывания и сопровождения, тут нужно исходить из критичности сервиса для вашего бизнеса, каким-то приложениям нужен полноценный, горячий HA-кластер, каким-то хватит холодного резерва, а каким-то можно и не делать резерв совсем.
Но нужно учитывать, что отказоустойчивость на layer4 это только верхушка огромного айсберга кластеризации, гораздо важнее и сложнее обеспечить отказоустойчивость на уровне серверов приложений и баз данных. Но еще раз подчеркну, GEO-кластер далеко не всем подходит в силу высокой стоимости развертывания и сопровождения, тут нужно исходить из критичности сервиса для вашего бизнеса, каким-то приложениям нужен полноценный, горячий HA-кластер, каким-то хватит холодного резерва, а каким-то можно и не делать резерв совсем.
Переброс AS используется для этих целей весьма давно и удачно, и если проекты действительно важны регаете AS + IP блок и прекрасно себе живете.
У нас это работает без всяких смен ДНС — одна точка в Москве, другая в Норвегии, если Москва целиком отрубится, трафик ре-роутится на те же самые ИП-адреса (да-да, без всяких смен ДНС) и доступен в течение 10-30 секунд как правило (в зависимости от того насколько удачно вы попали в промежуток BGP update). Пример такого сайта — www.passatclub.ru, почитайте форумы, там много об этом написано. У людей постоянно падал сервер из-за нестабильности/нагрузки, после кластеризации они забыли вообще о своих проблемах.
Может быть я смотрю на это несколько просто, потому что мы имеем LIR статус, и стоит сегмент и своя AS действительно недорого, вопрос просто понимания что бесплатного сыра не бывает, но также и того что это сыр, а не золотой брусок, так что имхо оно по карману очень многим.
Минусовой момент в этом — RIPE не дает блоки под AS маршрутизацию меньше чем /24, а это означает что если у вас куча клиентов на одном сегменте этом, все они синхронно перемахнутся на вторую точку кластера. В противном случае Вам придется регать /24 под каждого клиента, но это уже граничит с абсурдом :)
У нас это работает без всяких смен ДНС — одна точка в Москве, другая в Норвегии, если Москва целиком отрубится, трафик ре-роутится на те же самые ИП-адреса (да-да, без всяких смен ДНС) и доступен в течение 10-30 секунд как правило (в зависимости от того насколько удачно вы попали в промежуток BGP update). Пример такого сайта — www.passatclub.ru, почитайте форумы, там много об этом написано. У людей постоянно падал сервер из-за нестабильности/нагрузки, после кластеризации они забыли вообще о своих проблемах.
Может быть я смотрю на это несколько просто, потому что мы имеем LIR статус, и стоит сегмент и своя AS действительно недорого, вопрос просто понимания что бесплатного сыра не бывает, но также и того что это сыр, а не золотой брусок, так что имхо оно по карману очень многим.
Минусовой момент в этом — RIPE не дает блоки под AS маршрутизацию меньше чем /24, а это означает что если у вас куча клиентов на одном сегменте этом, все они синхронно перемахнутся на вторую точку кластера. В противном случае Вам придется регать /24 под каждого клиента, но это уже граничит с абсурдом :)
мне можете не рассказывать )
habrahabr.ru/blogs/studiobusiness/90349/#comment_2720745
А насчёт:
>RIPE не дает блоки под AS маршрутизацию меньше чем /24
это просто потому, что префикс меньше /24 нельзя проаннонсировать в bgp
habrahabr.ru/blogs/studiobusiness/90349/#comment_2720745
А насчёт:
>RIPE не дает блоки под AS маршрутизацию меньше чем /24
это просто потому, что префикс меньше /24 нельзя проаннонсировать в bgp
>RIPE не дает блоки под AS маршрутизацию меньше чем /24
это просто потому, что префикс меньше /24 нельзя проаннонсировать в bgp
Что я собственно и сказал :)
это просто потому, что префикс меньше /24 нельзя проаннонсировать в bgp
Что я собственно и сказал :)
«RIPE не даёт» и «нельзя проаннонсировать в BGP» совсем разные вещи. Более того, это неправда, что RIPE не дает, на прошлом тренинге райповском я спросил, можно ли все-таки взять скажем /25, мне сказали, что можно, если вы очень попросите ) Но они просто этого не рекомендуют, т.к. это лишено смысла.
снятие полноценного бекапа с работающего сервера у меня вызывает легкое сомнениеВ принципе, Вы всё понимаете правильно. Дело в том, что под «полноценным бэкапом» в разных случаях понимают разные вещи.
Если у Вас шаредхостинг, стоит сотня чужих проектов, которые Вы никак не контролируете и не можете контролировать в принципе, которые зачастую написаны криво (напр. данные хранят кто в файлах кто в базе, обновляют эти данные не атомарно/без использования транзакций, etc.) — тогда всё, что Вы можете, уже описано в предыдущих комментариях. Да, описанные подходы не гарантируют того, что вся сотня чужих проектов заведётся на зеркальном сервере/восстановится из бэкапов в целостном состоянии. Но! Простые, либо правильно написанные, проекты заведутся все; из оставшихся кривонаписанных большей части просто повезёт и данные будут либо в целостном состоянии либо нарушения будут незначительны и могут вообще никогда не проявится; и только у малой части будут проблемы… причём эти проблемы, по большому счёту, будут вызваны их собственным кривым кодом, так что Вы можете умыть руки с более-менее чистой совестью.
У нас ситуация немного другая. Проектов десятки, но все пишутся и контролируются нами, и все изначально пишутся с поддержкой возможности делать гарантированно целостные бэкапы. В таких условиях никаких проблем с получением «полноценного бэкапа» работающего сервера нет вообще.
Будьте добры, расскажите поподробнее про «изначально пишутся с поддержкой возможности делать гарантированно целостные бэкапы».
Да всё просто — используются shared и exclusive блокировки. Реализовать их можно разными способами, у нас сделано через flock(2). flock выбран по двум причинам: независимость от базы данных и гарантия снятия блокировки при завершении процесса любым способом.
Все приложения проекта (CGI- и cron- скрипты, FastCGI сервис, скрипты обработки входящих писем, сетевые сервисы, утилиты командной строки) пишутся так, чтобы перед доступом к любым данным (файлы проекта и/или база данных) они ставили shared lock. Чтобы всё упростить, обычно недолго работающие скрипты просто ставят shared lock при запуске (при выходе процесса блокировка снимается автоматически), таким образом достаточно добавить в эти скрипты всего одну строчку. С постоянно работающими сетевыми сервисами вроде FastCGI немного сложнее — постоянно блокировку удерживать нельзя, поэтому обычно приходится ставить блокировку в момент получения входящего запроса и снимать перед отправкой ответа, но здесь уже всё зависит от конкретного сервиса.
Суть в том, что блокировки не ставятся на каждый отдельный доступ к данным, а ставятся на более длительные высокоуровневые операции, поэтому добавить поддержку блокировок в проект очень просто и требует обычно от одной до 2-4-6 строк кода на каждое приложение.
Соответственно, перед началом бэкапа ставится exclusive lock, который удерживается в процесса бэкапа и гарантирует, что файлы и база проекта находятся в целостном состоянии. Тот же exclusive lock используется помимо бэкапа для deploy (обновления проекта) и для ручного вмешательства админа при необходимости.
Поскольку в процессе бэкапа проект фактически остановлен, то требуется ускорить бэкап. Обычно для этого достаточно поддержки инкрементальных бэкапов как файлов так и базы проекта. Иногда для того, чтобы сделать возможными быстрые инкрементальные бэкапы большой базы приходится менять схему базы таким образом, чтобы вынести все объёмные данные в таблицы, с которыми работают исключительно через SELECT и INSERT — если нет ни UPDATE ни DELETE, то такие таблицы можно инкрементально бэкапить. При таком подходе проекты с достаточно большими базами удаётся бэкапить буквально за пару секунд.
Нашу реализацию блокировок (perl) можно посмотреть внутри этого архива в модуле Narada::Lock, там есть кое-какие нюансы.
Все приложения проекта (CGI- и cron- скрипты, FastCGI сервис, скрипты обработки входящих писем, сетевые сервисы, утилиты командной строки) пишутся так, чтобы перед доступом к любым данным (файлы проекта и/или база данных) они ставили shared lock. Чтобы всё упростить, обычно недолго работающие скрипты просто ставят shared lock при запуске (при выходе процесса блокировка снимается автоматически), таким образом достаточно добавить в эти скрипты всего одну строчку. С постоянно работающими сетевыми сервисами вроде FastCGI немного сложнее — постоянно блокировку удерживать нельзя, поэтому обычно приходится ставить блокировку в момент получения входящего запроса и снимать перед отправкой ответа, но здесь уже всё зависит от конкретного сервиса.
Суть в том, что блокировки не ставятся на каждый отдельный доступ к данным, а ставятся на более длительные высокоуровневые операции, поэтому добавить поддержку блокировок в проект очень просто и требует обычно от одной до 2-4-6 строк кода на каждое приложение.
Соответственно, перед началом бэкапа ставится exclusive lock, который удерживается в процесса бэкапа и гарантирует, что файлы и база проекта находятся в целостном состоянии. Тот же exclusive lock используется помимо бэкапа для deploy (обновления проекта) и для ручного вмешательства админа при необходимости.
Поскольку в процессе бэкапа проект фактически остановлен, то требуется ускорить бэкап. Обычно для этого достаточно поддержки инкрементальных бэкапов как файлов так и базы проекта. Иногда для того, чтобы сделать возможными быстрые инкрементальные бэкапы большой базы приходится менять схему базы таким образом, чтобы вынести все объёмные данные в таблицы, с которыми работают исключительно через SELECT и INSERT — если нет ни UPDATE ни DELETE, то такие таблицы можно инкрементально бэкапить. При таком подходе проекты с достаточно большими базами удаётся бэкапить буквально за пару секунд.
Нашу реализацию блокировок (perl) можно посмотреть внутри этого архива в модуле Narada::Lock, там есть кое-какие нюансы.
«Суть в том, что блокировки не ставятся на каждый отдельный доступ к данным, а ставятся на более длительные высокоуровневые операции,»
И у вас не возникает бутылочного горлышка, когда несколько скриптов обращаются к одной блокировке?
«в процессе бэкапа проект фактически остановлен»
Честно говоря, это меня смущает больше всего.
«таблицы, с которыми работают исключительно через SELECT и INSERT — если нет ни UPDATE ни DELETE»
Насколько я понимаю, с такими таблицами очень неудобно работать. Вы наверное держите при этом оперативные таблицы с теми же данными, которые не надо бекапить, для удобства извлечения информации?
И у вас не возникает бутылочного горлышка, когда несколько скриптов обращаются к одной блокировке?
«в процессе бэкапа проект фактически остановлен»
Честно говоря, это меня смущает больше всего.
«таблицы, с которыми работают исключительно через SELECT и INSERT — если нет ни UPDATE ни DELETE»
Насколько я понимаю, с такими таблицами очень неудобно работать. Вы наверное держите при этом оперативные таблицы с теми же данными, которые не надо бекапить, для удобства извлечения информации?
И у вас не возникает бутылочного горлышка, когда несколько скриптов обращаются к одной блокировке?Нет, т.к. это shared lock. На установку блокировки уходит примерно 0.00007 секунды.
Честно говоря, это меня смущает больше всего.При том, что инкрементальный бэкап занимает пару секунд — это не проблема, пользователи даже не успевают заметить момент бэкапа или обновления проекта. При бэкапе, под установленным exclusive lock выполняются только необходимые операции, например для инкрементально бэкапящихся таблиц только запоминается id последней записи. Потом эксклюзивная блокировка снимается, и пока проект продолжает работать как обычно, без спешки завершается процесс бэкапа — делаются инкрементальные дампы таблиц (по запомненный id), файл с бэкапом сжимается и заливается на бэкап-сервер.
Насколько я понимаю, с такими таблицами очень неудобно работать. Вы наверное держите при этом оперативные таблицы с теми же данными, которые не надо бекапить, для удобства извлечения информации?Не совсем так. Простой пример: есть большая таблица с кучей текстовых данных, которые изредка изменяются. Инкрементально бэкапить такую таблицу невозможно. Но можно создать рядом таблицу-справочник, с двумя полями: id и text, перенести в неё все текстовые данные из основной таблицы, а в основной вместо текстовых полей хранить id записей из таблицы-справочника. В таблице-справочнике данные никогда не удаляются и не изменяются, она большая, но её можно инкрементально бэкапить. Основную таблицу инкрементально бэкапить по-прежнему нельзя, но там теперь только id-шки, она стала крохотной и будет моментально бэкапится целиком. Работать с такой таблицей стало немного сложнее из-за лишних join-ов… но ведь это не требуется проделывать со всеми таблицами в проекте, достаточно двух-трёх самых объёмных, которые сильно тормозили бэкап.
«У меня хороший сервер в макхосте, анлим по трафику и рейды. „
Был.
Был.
А в чем преимущество?
Пользователь, у которого DNS-ответ был закэширован, в любом случае будет стучаться по старому IP до истечения времени TTL (или дольше, если операционка и/или браузер кэшируют агрессивнее).
Пользователь, у которого ничего не было закэшировано, полезет к DNS-серверам. Присутствие нерабочих записей ns1, ns2 только замедлит первоначальный резолвинг.
Плюс вижу в том, что после выхода основного сервера в онлайн, новые запросы сами собой пойдут на него.
Но вот вопрос: когда несколько DNS прописано у регистратора, клиенты обращаются к ним случайным образом или перебирают список по порядку?
Пользователь, у которого DNS-ответ был закэширован, в любом случае будет стучаться по старому IP до истечения времени TTL (или дольше, если операционка и/или браузер кэшируют агрессивнее).
Пользователь, у которого ничего не было закэшировано, полезет к DNS-серверам. Присутствие нерабочих записей ns1, ns2 только замедлит первоначальный резолвинг.
Плюс вижу в том, что после выхода основного сервера в онлайн, новые запросы сами собой пойдут на него.
Но вот вопрос: когда несколько DNS прописано у регистратора, клиенты обращаются к ним случайным образом или перебирают список по порядку?
у hqhost.net держим сервер за $75 под бекап. входящий трафф бесплатен.
копируем по rsync раз в неделю с 3х серверов.
копируем по rsync раз в неделю с 3х серверов.
> Что сделать, чтобы фокусы всяких Макхостов были не страшны?
Мое мнение такого, что выход намного проще, чем описанные автором решения: достаточно не экономитькопейку пару тысяч рублей на том, от чего зависит весь ваш электронный бизнес!
Всем с детского сада известна старая русская поговорка «скупой платит дважды», которая как ничто лучше демонстрирует все происходящее:
30.000 человек/компаний ринулись за халявой (анлим трафом, низкими ценами, вкусными параметрами виртуального хостинга) и, как обычно бывает в нашей любимой стране, получили жесткий облом…
Никто из нас (или почти никто) не знает нюансов терок макхоста с оверсаном, а ведь возможен сценарий, что у макхоста тупо нет денег оплатить долги (или аренду стоек): ведь в it-среде зарплаты не как у дворников, маломальский штат на практике выжирает огромные денежные ресурсы (знаю не по наслышке) и есть вероятность, что они просто не рассчитали денежные потоки и плавно ушли в глубокий минус, оказавшись зажатыми между низкими поступлениями от клиентов и большими расходами на траф…
Вывод ЛИЧНО МОЙ таков: если хостинг является критично важным для бизнеса компании, то экономить на нем просто не дальновидно… Я держу свои важные домены на Мастерхосте (хотя понимаю, что нехило переплачиваю), но зато знаю на 100%, что эти жадные ребята никуда не пропадут, когда на них льется такое шальное бабло;)
Мое мнение такого, что выход намного проще, чем описанные автором решения: достаточно не экономить
Всем с детского сада известна старая русская поговорка «скупой платит дважды», которая как ничто лучше демонстрирует все происходящее:
30.000 человек/компаний ринулись за халявой (анлим трафом, низкими ценами, вкусными параметрами виртуального хостинга) и, как обычно бывает в нашей любимой стране, получили жесткий облом…
Никто из нас (или почти никто) не знает нюансов терок макхоста с оверсаном, а ведь возможен сценарий, что у макхоста тупо нет денег оплатить долги (или аренду стоек): ведь в it-среде зарплаты не как у дворников, маломальский штат на практике выжирает огромные денежные ресурсы (знаю не по наслышке) и есть вероятность, что они просто не рассчитали денежные потоки и плавно ушли в глубокий минус, оказавшись зажатыми между низкими поступлениями от клиентов и большими расходами на траф…
Вывод ЛИЧНО МОЙ таков: если хостинг является критично важным для бизнеса компании, то экономить на нем просто не дальновидно… Я держу свои важные домены на Мастерхосте (хотя понимаю, что нехило переплачиваю), но зато знаю на 100%, что эти жадные ребята никуда не пропадут, когда на них льется такое шальное бабло;)
ну, даже на слабеньком шареде от Мастерхоста можно до фига развернуть (если настроить кэширование). В этом плане еще не понятно, что дешевле выходит :)
Как пример — www.speedingupwebsite.com
Как пример — www.speedingupwebsite.com
Пользоваться забугорным хостингом.
все по опыту:
забугорный хостинг не панацея если трафика на сотни мегабит и он русский — разоритесь платить, тут дешевле. посмотрите почем стоит выделенный реальный 100М анлим — дешевле 4-5евро в Европе не будет, обычно все тарифы имеют лимит.
забугорный хостинг так же не панацея если там видео, игры и т.п. — пользователи с РТК и из-за Урала начинают выть и сваливать из-за пинга в сотни мс.
Так что не все так однозначно. Имеет смысл иметь сервер в РФ на приличном коло с хорошей связаностью из ОПГ или аналогичных клиентов + резерв в европе + ДНС сервер на нейтральной площадке, который может балансировать и по географии и по доступности серверов.
забугорный хостинг не панацея если трафика на сотни мегабит и он русский — разоритесь платить, тут дешевле. посмотрите почем стоит выделенный реальный 100М анлим — дешевле 4-5евро в Европе не будет, обычно все тарифы имеют лимит.
забугорный хостинг так же не панацея если там видео, игры и т.п. — пользователи с РТК и из-за Урала начинают выть и сваливать из-за пинга в сотни мс.
Так что не все так однозначно. Имеет смысл иметь сервер в РФ на приличном коло с хорошей связаностью из ОПГ или аналогичных клиентов + резерв в европе + ДНС сервер на нейтральной площадке, который может балансировать и по географии и по доступности серверов.
xname.org/ — This Free DNS hosting service is provided to help people that don't want to lose time and money with providers not always reactive to DNS changes.
Не то?
Не то?
Степан, всё прошло хорошо? Всё живо?
Для маленьких(или относительно маленьких) проектов можно заливать бэкапы на домашнюю машину. Там же и развернуться(на время, разумеется) в случае ахтунга. Дёшево и сердито.
Вопрос заданный в топике на сегодняшний день решается на 99,99,% переносом критических сайтов и приложений в облако. Там гарантируются и бэкапы и stand up сервисов на 98 %, причем об этом разработчикам не нужно заботится, все происходит автоматически.
Главное есть из чего выбрать:
Amazon Web Services aws.amazon.com/
Sun Cloud www.sun.com/solutions/cloudcomputing/
На подходе для России www.microsoft.com/windowsazure/
Главное есть из чего выбрать:
Amazon Web Services aws.amazon.com/
Sun Cloud www.sun.com/solutions/cloudcomputing/
На подходе для России www.microsoft.com/windowsazure/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что сделать, чтобы фокусы всяких Макхостов были не страшны?