Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 79
Приветствую!
>Сегодня у Scalaxy был сбой, и с 19:32 по 20:54 Московского времени сервера в облаке были недоступны.
Уточню, что недоступна была некоторая часть виртуальных машин. Не все, как может показаться из вашего сообщения.
Все оповещения о работах/проблемах в twitter @scalaxy и коммъюнити на oversun.zendesk.com, а так же поддержка которая круглосуточно готова ответить на любой вопрос, по e-mail или по телефону, о том, что случилось и когда будет исправлено.
>Сегодня у Scalaxy был сбой, и с 19:32 по 20:54 Московского времени сервера в облаке были недоступны.
Уточню, что недоступна была некоторая часть виртуальных машин. Не все, как может показаться из вашего сообщения.
Все оповещения о работах/проблемах в twitter @scalaxy и коммъюнити на oversun.zendesk.com, а так же поддержка которая круглосуточно готова ответить на любой вопрос, по e-mail или по телефону, о том, что случилось и когда будет исправлено.
Совковость вашего ответа over 9000
Отличная позиция. Вы только что потеряли меня как клиента.
До свидания.
До свидания.
Не одного, а много потенциальных клиентов.
Я описал возможные способы получения информации о проблеме и сроках её решения, в случае с Оверсан-Скалакси на данный момент. Не вижу, где можно было интерпретировать мои слова по-другому и найти какую-либо позицию в отношении к Оверсан или пользователям облака, правда, простите.
Внимательно посмотрел оный oversun.zendesk.com — не увидел сообщения.
Да какая разница. Мне парсер их хелпдеска написать чтобы самому раз в полчаса не чекать? )
Клиент: «Почему до сих пор нет сообщения в zenddesk о времени начала и продолжительности неработоспособности серверов (не только наших проектов, а вообще всех)?»
Контора: «Оповещение о недоступности серверов в облаке не было добавлено в публичный поток новостей, поскольку неполадки коснулись лишь небольшой части наших клиентов, в том числе, к сожалению, Вашего.»
Хорошо, конечно… но почему бы не оповещать эту «небольшую часть клиентов» в индивидуальном порядке, раз их число настолько ничтожно, что не стоит из-за этого «украшать» публичный поток?
Контора: «Оповещение о недоступности серверов в облаке не было добавлено в публичный поток новостей, поскольку неполадки коснулись лишь небольшой части наших клиентов, в том числе, к сожалению, Вашего.»
Хорошо, конечно… но почему бы не оповещать эту «небольшую часть клиентов» в индивидуальном порядке, раз их число настолько ничтожно, что не стоит из-за этого «украшать» публичный поток?
Что-то здесь не то… на дзендеске до сих пор ничего не появилось, или я не там смотрю?
Вам, Azy, ещё повезло… у нас так вообще один (из тех, что на оверсане) проект, судя по нагиосу, не откликался до 22:00.
Отдельные деньги, которые платятся за поддержку, а не за хостинг, тоже как-то на процесс «информирования клиентов» не повлияли. Плохо, товарищи… очень плохо! Оценка — неудовлетворительно!
Ответ хостера по данной проблеме:
Вчера у нас был сбой в облаке — несколько хостов виртуализации перешли в неработоспособное состояние и система мониторинга не оповестила администраторов (по ошибке, вообще такое оповещение всегда срабатывает). Поиск решения проблемы несколько затянулся, вдобавок к тому, что сама проблема была обнаружена не сразу. Сейчас необходимые новые уведомления в системе мониторинга добавлены и неприятностей такого характера больше не будет. (лир.отст. — это мы ещё посмотрим)
Процесс «поднятия» серверов с неработоспособных хостов виртуализации происходил в порядке, в котором они были расположены в БД Zen. Таким образом задержка ***.ru в какой-то степени связана с этим. Плюс к этому, сервер некоторое время находился в swap-е, в то время как сотрудники были уверены, что он еще не «поднялся» с неработоспособного хоста виртуализации на другом (новом) хосте. Надеемся, что такие недоразумения впредь происходить не будут.
Вам, Azy, ещё повезло… у нас так вообще один (из тех, что на оверсане) проект, судя по нагиосу, не откликался до 22:00.
Отдельные деньги, которые платятся за поддержку, а не за хостинг, тоже как-то на процесс «информирования клиентов» не повлияли. Плохо, товарищи… очень плохо! Оценка — неудовлетворительно!
Ответ хостера по данной проблеме:
Вчера у нас был сбой в облаке — несколько хостов виртуализации перешли в неработоспособное состояние и система мониторинга не оповестила администраторов (по ошибке, вообще такое оповещение всегда срабатывает). Поиск решения проблемы несколько затянулся, вдобавок к тому, что сама проблема была обнаружена не сразу. Сейчас необходимые новые уведомления в системе мониторинга добавлены и неприятностей такого характера больше не будет. (лир.отст. — это мы ещё посмотрим)
Процесс «поднятия» серверов с неработоспособных хостов виртуализации происходил в порядке, в котором они были расположены в БД Zen. Таким образом задержка ***.ru в какой-то степени связана с этим. Плюс к этому, сервер некоторое время находился в swap-е, в то время как сотрудники были уверены, что он еще не «поднялся» с неработоспособного хоста виртуализации на другом (новом) хосте. Надеемся, что такие недоразумения впредь происходить не будут.
И у меня упало вчера очень неприятно. Хорошо вовремя увидел — какраз ковырялся в консоли… А ведь у меня там product-сервер. Для такого типа хостинга падения серверов — неприемлемо, но в два раза более неприемлемо — не информировать оперативно (минуты а не часы).
что-то не вижу я для себя перспектив переводить своих подопечных в облака… Ой, не вижу :(
За последний полгода таких новостей на главной все больше и больше.
Облако если падает, то все сразу.
А если один сервер из сотни клиентов упал, то остальным от этого вреда нет. И репутация — в порядке
За последний полгода таких новостей на главной все больше и больше.
Облако если падает, то все сразу.
А если один сервер из сотни клиентов упал, то остальным от этого вреда нет. И репутация — в порядке
Я как человек, занимающийся оными вопросами (к Оверсану не имею никого отношения) могу сказать, что легенда, что «облака падают сразу и полностью» — неправда. В сколь-либо значительной конфигурации хосты всех (известных мне) гипервизоров и тулстеков обладают автономностью. То есть без панельки управления останетесь, без статистики и т.д, но виртуалка продолжит работать. Средняя консолидация «толстой виртуализации» (когда ядро в виртуалке у каждого своё) — около 1:40-1:70, то есть зависание одного хоста (его невозможно избежать, т.к. даже многобитовый ECC не даёт полной защиты от повреждения содержимого памяти всякой космической хренью) касается малого числа клиентов.
Падение СХД — хуже. Консолидация там выше (зависит от сложности и мощщи оной СХД), могу себе представить СХД, которая обслуживает пару тысяч виртуалок. Но опять же, в сколь-либо крупном облаке СХД обычно исчисляются десятками, если не стойками.
Таким образом, единственной «общей» точкой отказа может быть отказ электропитания в ДЦ (и другие проблемы «реального мира») — но они ровно так же ударят по любого рода размещению, будь то железный сервер или шаред хостинг.
В принципе, я могу представить себе отказ из-за фатального сбоя системы управления (например, добрый дядя сказал «выключить *» с консоли), но про такие случаи я как раз не слышал.
А все случаи, какие я слышал или наблюдал, всегда были связаны с отказом компонент — и тут я не вижу разницы с шаред хостингом или VDS.
А вот шуму это производит больше, потому что люди интуитивно ожидают от облаков совершенной надёжности (и небольшой даунтайм шаред хостинга воспринимают понимающе «ну, бывает», а такой же даунтайм машины в облаке — как вселенскую катастрофу)… А технологии FT (которые позволят сделать жизнь виртуалки более надёжной, чем жизнь хоста, на которой она работает) всё ещё находятся в состоянии deep research, и до продакта им далековато. Плюс, никто не обещал, что это будет так же дёшево и быстро.
Падение СХД — хуже. Консолидация там выше (зависит от сложности и мощщи оной СХД), могу себе представить СХД, которая обслуживает пару тысяч виртуалок. Но опять же, в сколь-либо крупном облаке СХД обычно исчисляются десятками, если не стойками.
Таким образом, единственной «общей» точкой отказа может быть отказ электропитания в ДЦ (и другие проблемы «реального мира») — но они ровно так же ударят по любого рода размещению, будь то железный сервер или шаред хостинг.
В принципе, я могу представить себе отказ из-за фатального сбоя системы управления (например, добрый дядя сказал «выключить *» с консоли), но про такие случаи я как раз не слышал.
А все случаи, какие я слышал или наблюдал, всегда были связаны с отказом компонент — и тут я не вижу разницы с шаред хостингом или VDS.
А вот шуму это производит больше, потому что люди интуитивно ожидают от облаков совершенной надёжности (и небольшой даунтайм шаред хостинга воспринимают понимающе «ну, бывает», а такой же даунтайм машины в облаке — как вселенскую катастрофу)… А технологии FT (которые позволят сделать жизнь виртуалки более надёжной, чем жизнь хоста, на которой она работает) всё ещё находятся в состоянии deep research, и до продакта им далековато. Плюс, никто не обещал, что это будет так же дёшево и быстро.
amarao, я не совсем об этом.
наберите в поиске «Селектел»…
Два поста в блоге «негодую». По-моему, и третий был, когда были проблемы с восстановлением резервных копий (или с чем-то еще, я не особо слежу и радуюсь чужим неудачам, пусть и коллег по цеху).
То же самое можно и про Скалакси сказать. Про Амазон были вести, помните :-)
Это отнюдь не значит, что компании плохие.
Я вел лишь к тому, что падение инфраструктуры облака длится дольше и несет лучи горя для репутации компании больше, чем для обычного аппаратного «Хетцнероподобного» хостинга (назовем его «классическим»). Потому что «падают» все клиенты сразу. И жалуются тоже все сразу
Есть несколько тому причин. Основные проблемы хостинга какие? Оптику «автодоровцы» пересапали, свет отключили на неделю или друзья в погонах грабить пришли. Все решается относительно быстро: оптику ночью приезжает чинить сварщик по оптике за 2 см денег, мавр неспешно подливает бензин в дизель-генератор а «друзья» пьют чай в кабинете директора.
Это аппаратные проблемы. Есть еще и особый случай, когда один конкретный сервер одного конкретного клиента упал. Так он — один, клиент. А их — еще сотни довольных. Да и у этого клиента еще 4 рабочих сервера в нашем же ДЦ стоят и жужжат. В результате, он погорюет, посчитает простой, вздохнет, и будет дальше ждать восстановления работоспособности. Никто нигде не ругается, никто не валит из компании табунов в 4 десятка серверов. Все довольны.
Вы правы, падение облака шуму производит больше. И не потому, что люди интуитивно ожидают больше надежности (все везде относительно одинаково в рамках одной ценовой категории). В облачном хостинге появляется дополнительное слабое звено — его инфраструктура (совокупность п/о, идей и технологий), которая, как ни крути, не идеальна. И, к тому же, тянет всю компанию вниз, вместе с седеющими маркетологами, если не дай Б.г что случается.
В отличие от «обычного» хостинга.
наберите в поиске «Селектел»…
Два поста в блоге «негодую». По-моему, и третий был, когда были проблемы с восстановлением резервных копий (или с чем-то еще, я не особо слежу и радуюсь чужим неудачам, пусть и коллег по цеху).
То же самое можно и про Скалакси сказать. Про Амазон были вести, помните :-)
Это отнюдь не значит, что компании плохие.
Я вел лишь к тому, что падение инфраструктуры облака длится дольше и несет лучи горя для репутации компании больше, чем для обычного аппаратного «Хетцнероподобного» хостинга (назовем его «классическим»). Потому что «падают» все клиенты сразу. И жалуются тоже все сразу
Есть несколько тому причин. Основные проблемы хостинга какие? Оптику «автодоровцы» пересапали, свет отключили на неделю или друзья в погонах грабить пришли. Все решается относительно быстро: оптику ночью приезжает чинить сварщик по оптике за 2 см денег, мавр неспешно подливает бензин в дизель-генератор а «друзья» пьют чай в кабинете директора.
Это аппаратные проблемы. Есть еще и особый случай, когда один конкретный сервер одного конкретного клиента упал. Так он — один, клиент. А их — еще сотни довольных. Да и у этого клиента еще 4 рабочих сервера в нашем же ДЦ стоят и жужжат. В результате, он погорюет, посчитает простой, вздохнет, и будет дальше ждать восстановления работоспособности. Никто нигде не ругается, никто не валит из компании табунов в 4 десятка серверов. Все довольны.
Вы правы, падение облака шуму производит больше. И не потому, что люди интуитивно ожидают больше надежности (все везде относительно одинаково в рамках одной ценовой категории). В облачном хостинге появляется дополнительное слабое звено — его инфраструктура (совокупность п/о, идей и технологий), которая, как ни крути, не идеальна. И, к тому же, тянет всю компанию вниз, вместе с седеющими маркетологами, если не дай Б.г что случается.
В отличие от «обычного» хостинга.
в отличие от «облачного», простите. 5erg, иди спать…
Я прекрасно понимаю разницу между «железным сервером» и любого рода сложными сервисами. Разумеется, сервисы накладывают дополнительный оверхед на management-систему.
Но я не вижу разницы между падением shared-хостинга и падением облака. Более того, я думаю (никогда shared-хостингом не занимался, так что лишь предполагаю), что падение железного хоста в облаке (не важно по какой причине — взбесившийся гипервизор или подвисший драйвер блочных устройств) будет устранено в течение единиц минут с момента обнаружения этого события. Сколько будет восстанавливаться shared-хостинг не знаю, но могу себе представить fsck на 2-3 часа.
СХД стартуют медленее, но у меня регламентное время нулевого перезапуска (то бишь «всё с нуля», как после полного обесточивания) — около часа, точнее, до начала перезапуска 10 минут, а дальше уже старт клиентских машин.
Повторю, для ДЦ коло — самый безгеморройный и безответственный бизнес. Дал электричество и интернет, гарантированное время «пропуска» к железке, всё, остальное проблемы клиента. Дальше дедики — тут уже надо держать запас железа и людей в ДЦ для замены.
А все остальные услуги хостинга требуют всё больший объём усилий по сопровождению (ради чего и делаются — выше прибавочная стоимость, отбираемая у пролетариата, выше доходы у эксплуатирующего капиталиста). И тут уже нет разницы — VDS, облако или шаред хостинг.
С точки же зрения «довольного/недовольного» клиента ситуация другая. От того, что он один или он не один — меняется только моральная оценка произошедшего, но не последствия. А последствия смерти дедика куда страшнее, чем любая авария на облаке (ну, кроме «drop cloud*, drop backup*, drop admin*») — время даунтайма значительно больше будет.
Относительно наших проблем — да, были. Сейчас перерабатываем те места, где было узко, надеемся, после завершения этих работ о сбое на конкретном СХД будет знать только админ, а не клиенты.
Мысль в двух словах: падение shared хостинга, VDS и облака одинаково по времени починки и даунтайму.
Но я не вижу разницы между падением shared-хостинга и падением облака. Более того, я думаю (никогда shared-хостингом не занимался, так что лишь предполагаю), что падение железного хоста в облаке (не важно по какой причине — взбесившийся гипервизор или подвисший драйвер блочных устройств) будет устранено в течение единиц минут с момента обнаружения этого события. Сколько будет восстанавливаться shared-хостинг не знаю, но могу себе представить fsck на 2-3 часа.
СХД стартуют медленее, но у меня регламентное время нулевого перезапуска (то бишь «всё с нуля», как после полного обесточивания) — около часа, точнее, до начала перезапуска 10 минут, а дальше уже старт клиентских машин.
Повторю, для ДЦ коло — самый безгеморройный и безответственный бизнес. Дал электричество и интернет, гарантированное время «пропуска» к железке, всё, остальное проблемы клиента. Дальше дедики — тут уже надо держать запас железа и людей в ДЦ для замены.
А все остальные услуги хостинга требуют всё больший объём усилий по сопровождению (ради чего и делаются — выше прибавочная стоимость, отбираемая у пролетариата, выше доходы у эксплуатирующего капиталиста). И тут уже нет разницы — VDS, облако или шаред хостинг.
С точки же зрения «довольного/недовольного» клиента ситуация другая. От того, что он один или он не один — меняется только моральная оценка произошедшего, но не последствия. А последствия смерти дедика куда страшнее, чем любая авария на облаке (ну, кроме «drop cloud*, drop backup*, drop admin*») — время даунтайма значительно больше будет.
Относительно наших проблем — да, были. Сейчас перерабатываем те места, где было узко, надеемся, после завершения этих работ о сбое на конкретном СХД будет знать только админ, а не клиенты.
Мысль в двух словах: падение shared хостинга, VDS и облака одинаково по времени починки и даунтайму.
Не соглашусь. Мало где шаред хостинг завязан на центральную СХД — дешевле локальные диски в софтмиррор собрать, да бэкапить периодически. Юзерам для фпт/ssh доступа выдается IP конечного физического сервера. Централизованным у хостинга остается лишь сеть (и да, «поднимать» ее куда проще, хотя пример Яндекса и говорит об обратном)
Товарищи с netapp'ом меня начинают убеждать. Я считал, что большинство наших конкурентов тоже используют сегментирование СХД, но, возможно, я ошибаюсь…
Большинство использует сегментирование из-за дешевезны такого подхода, одна полка с дисками от NetApp стоит как пяток ваших ящиков от Супермикры :)
Но бывают исключения:
habrahabr.ru/company/cloudone/blog/117481/
Мне интересно как организованы сети хранения у таких гигантов как Amazon, Google и Microsoft. Серверы они заказывают у ODM, а вот с системами хранения всё немного сложнее.
Но бывают исключения:
habrahabr.ru/company/cloudone/blog/117481/
Мне интересно как организованы сети хранения у таких гигантов как Amazon, Google и Microsoft. Серверы они заказывают у ODM, а вот с системами хранения всё немного сложнее.
Но опять же, в сколь-либо крупном облаке СХД обычно исчисляются десятками, если не стойками.
Зачем в ДЦ десятки СХД, неужели не хватит пары больших NetApp'ов, дублирующих друг дружку?
Да конечно хватит. К ним ещё 2-3 сервера с топовыми ксеонами и вуаля — облако готово (:
зы. На самом деле, у хранилок в облаке основная проблема в пропускной способности к ним. А всякие большие netapp'ы и clariion'ы о пропускной способности нисколько не заботятся. Потому и нужны целые стойки.
зы. На самом деле, у хранилок в облаке основная проблема в пропускной способности к ним. А всякие большие netapp'ы и clariion'ы о пропускной способности нисколько не заботятся. Потому и нужны целые стойки.
Нет. Мы делали SAN на 10G, так вот я могу сказать, что у нас гигабит трафика на стор — редкость. И это при >10k IOPS. Сеть там совсем не является боттлнеком.
Когда все яйца в одной корзине (на одной площадке), особой отказоучтойчивости куча СХД не даст, а вот гемморой с обслуживанием вполне возможен.
Впрочем, про пропускную способность я не подумал, спасибо за ответ! :)
Впрочем, про пропускную способность я не подумал, спасибо за ответ! :)
А вот это, кстати, да, интересный вопрос. В этом контексте я могу согласиться «падает облако целиком». У нас предполагается довольно сильная независимость СХД друг от друга. А вот если закладываться на одно решение как single point. Но это явная глупость.
И даже если «толстый netapp». Он всегда один? Большое облако всё равно должно подразумевать сегментацию.
И даже если «толстый netapp». Он всегда один? Большое облако всё равно должно подразумевать сегментацию.
То есть когда это всё рушится, рушится всё сразу? Понятно, ок, начинаю думать, что миф может быть и не таким уж мифом.
Использовать единственную конструкцию для всего облака — ужас. Такое допустимо для management-интерфейсов, но никак не для инфраструктурных компонент.
Использовать единственную конструкцию для всего облака — ужас. Такое допустимо для management-интерфейсов, но никак не для инфраструктурных компонент.
А напротив пример гугля, который не использует single point of storage.
Давайте переформулирую обратно: в ПО для фейловера нет ошибок? Ни одного бага?
Ну, не могу сказать, что щупал руками, но да, читал.
А ещё я лично наблюдал баги в IOS'е, которые приводили к исчезновению трансляции nat'а. Оно, конечно, с VRRP не связано, но иллюстрирует мысль, что теоретическая модель «как это делается» отличается от практической реализации, и не всегда в правильную сторону.
Выяснять, что у нас «не то отреплицировалось» или узел стал мастером с outdated копией данных при более актуальной копии на других узлах — будет крайне неприятно. И степень неприятности прямо пропорциональна тому проценту инфраструктуры, который завязан на эту неприятность.
Таким образом, сегментирование — очевидный (хотя и ограниченный в возможностях) метод изоляции ошибок.
А ещё я лично наблюдал баги в IOS'е, которые приводили к исчезновению трансляции nat'а. Оно, конечно, с VRRP не связано, но иллюстрирует мысль, что теоретическая модель «как это делается» отличается от практической реализации, и не всегда в правильную сторону.
Выяснять, что у нас «не то отреплицировалось» или узел стал мастером с outdated копией данных при более актуальной копии на других узлах — будет крайне неприятно. И степень неприятности прямо пропорциональна тому проценту инфраструктуры, который завязан на эту неприятность.
Таким образом, сегментирование — очевидный (хотя и ограниченный в возможностях) метод изоляции ошибок.
Пользуйтесь зарубежными вариантами вроде Amazon — и будем вам счастье.
Ну, в общем-то да, русские «облака» — это тот же русский хостинг, только в профиль.
Есть же Amazon и ему подобные, зачем подвергать себя таким мучениям доверяясь русскому хостеру?
Есть же Amazon и ему подобные, зачем подвергать себя таким мучениям доверяясь русскому хостеру?
«Облака» — это значит, «будет падать», по определению самого облака. Смысл облаков в том, что вы можете взять жменьку серверов, организовать из их отказоустойчевый кластер и выход из строя одной из нод (нескольких) вам будет по ключу.
Если вы используете «облака», как vps — ваш fail.
Если вы используете «облака», как vps — ваш fail.
разумный комментарий
разрешите подписаться!
А мне всегда казалось, что облако — это платформа для разработики приложений (AWS, Azure, GAE) с офигительным SLA.
Но стараниями рекламщиков под облаками теперь понимают VPS с возможностью динамического раширения.
Но стараниями рекламщиков под облаками теперь понимают VPS с возможностью динамического раширения.
Sorry, не понял ваш комментарий AWS у вас с одной стороны платформа для разработки приложений и облако. С другой стороны AWS (EC2, EBS, VPC) это те сами VPS-ки с возможностью динамического, в том числе автоматического, расширения.
Вы сами не запутались в том, что вы считаете облаком, а что нет?
Вы сами не запутались в том, что вы считаете облаком, а что нет?
Вы путаете IaaS и PaaS. Тут обсуждается IaaS. Там «надёжность получившегося» — ответственность пользователя, а поставщик должен лишь показатели SLA выдерживать (кстати, где вы там видели «офигительный SLA?»).
А вот что делать построением надёжных пользовательских конфигураций поверх PaaS — я не знаю. И вообще, считаю PaaS дурной затеей (в силу труднопроводимой линии отреза между «частью оператора» и «частью пользователя»).
ЗЫ Разумеется, я заинтересованное лицо и хвалю своё болото.
А вот что делать построением надёжных пользовательских конфигураций поверх PaaS — я не знаю. И вообще, считаю PaaS дурной затеей (в силу труднопроводимой линии отреза между «частью оператора» и «частью пользователя»).
ЗЫ Разумеется, я заинтересованное лицо и хвалю своё болото.
И те и дургие сейчас называют облаками, даже SaaS туда иногда записывают.
По поводу PaaS всё довольно просто — провайдер предоставляет определённый API и сервисы с которыми работает разработчик, всё остальное (масштабирование, резервирование, обеспечение отказоустойчивости) является головной болью хостера. Преимущество такого подхода — прозрачное масштабирование, позволяющие уйти за пределы одного физического сервера (в случае IaaS придётся самому строить кластеры внутри инфраструктуры хостера).
По поводу PaaS всё довольно просто — провайдер предоставляет определённый API и сервисы с которыми работает разработчик, всё остальное (масштабирование, резервирование, обеспечение отказоустойчивости) является головной болью хостера. Преимущество такого подхода — прозрачное масштабирование, позволяющие уйти за пределы одного физического сервера (в случае IaaS придётся самому строить кластеры внутри инфраструктуры хостера).
Я всё это понимаю, я не понимаю, каким образом это должно оказаться надёжнее, чем решение на базе ИааС.
В случае IaaS вам даётся ВМ в рамках которой вы сами обеспечивает фейловер, в случае PaaS этим занимается хостер у котого больше ресурсов для решения задачи.
… И вот тут-то мы и переходим к проблеме «у хостера конфиг навернулся — все клиенты сосут лапу». Не нравится мне это.
Разрезание стека по инфраструктуре — куда более логичная вещь, чем резка в application layer.
Разрезание стека по инфраструктуре — куда более логичная вещь, чем резка в application layer.
Подобная проблема равносильна выходу из строя ДЦ у обычного хостера, так что клиенты сосут лапу в любом случае.
Выход из строя ДЦ = перенос серверов (физически) в другой ДЦ.
А как вы собираетесь «физически» переносить похеренные сбойнувшей кластеризованной системой данные? Кроме того, у ДЦ обычно есть совершенно простое и ясное SLA по электричеству, кондиционированию и коннективити.
Ни один поставщик СХД не подписывает подобного в отношении ПО. Подвести вылетевший винт/плату — да, конечно. А вот чтобы на сохранность данных при переходных процессах фейловера — нет.
А как вы собираетесь «физически» переносить похеренные сбойнувшей кластеризованной системой данные? Кроме того, у ДЦ обычно есть совершенно простое и ясное SLA по электричеству, кондиционированию и коннективити.
Ни один поставщик СХД не подписывает подобного в отношении ПО. Подвести вылетевший винт/плату — да, конечно. А вот чтобы на сохранность данных при переходных процессах фейловера — нет.
по-моему, многие так и не поняли. клауд — не панацея от сбоев и не серебряная пуля.
хотите надежности — запустите две/три/etc копии своих серверов в других регионах, настройте правильный failover и живите счастливо. и да, амазон тоже падает, и сбои довольно часты. для рассылки используется rss.
хотите надежности — запустите две/три/etc копии своих серверов в других регионах, настройте правильный failover и живите счастливо. и да, амазон тоже падает, и сбои довольно часты. для рассылки используется rss.
Мне, кажется, автор больше возмущен не падением «облака» (никто не застрахован), а тем, что такой (распиареный) серис как Scalaxy (а за ним компания Oversun) не может настроить нормальную систему уведомлений о проблемах для своих клиентов.
Мы так же используем их сервис и с технической точки зрения вопросов нет — все понятно, всё пока работает; и личный кабинет хороший, и графики рисуются. Но система уведомлений — твиттер и публичная страница на oversun.zendesk.com/home (ссылка на которую никоим образом не отображается на сайте, а есть только в личном кабинете), на которой до сих пор нет никаких данных о возникшей проблеме.
Ребят, 21 век на дворе — увас есть база почтовых адресов клиентов, ну сделайте скрипт рассылку о проблеме! Проблема не в том, что у вас упало. Среди нас такие же технари — у все всё ломается. Почините и будет снова всем счастье. Но напишите письмо, которое мы потом сможем показать начальству, что «да, о проблеме знаем, устраняем. как сделаем, напишем. всё».
Ну и ответ саппорта о вчерашней проблеме:
12-21 12:07 (MSK):
Здравствуйте, Владимир!
Оповещение о недоступности серверов в облаке не было добавлено в публичный поток новостей, поскольку неполадки коснулись лишь небольшой части наших клиентов, в том числе, к сожалению, Вашего.
Благодарим за сотрудничество.
Мы так же используем их сервис и с технической точки зрения вопросов нет — все понятно, всё пока работает; и личный кабинет хороший, и графики рисуются. Но система уведомлений — твиттер и публичная страница на oversun.zendesk.com/home (ссылка на которую никоим образом не отображается на сайте, а есть только в личном кабинете), на которой до сих пор нет никаких данных о возникшей проблеме.
Ребят, 21 век на дворе — увас есть база почтовых адресов клиентов, ну сделайте скрипт рассылку о проблеме! Проблема не в том, что у вас упало. Среди нас такие же технари — у все всё ломается. Почините и будет снова всем счастье. Но напишите письмо, которое мы потом сможем показать начальству, что «да, о проблеме знаем, устраняем. как сделаем, напишем. всё».
Ну и ответ саппорта о вчерашней проблеме:
12-21 12:07 (MSK):
Здравствуйте, Владимир!
Оповещение о недоступности серверов в облаке не было добавлено в публичный поток новостей, поскольку неполадки коснулись лишь небольшой части наших клиентов, в том числе, к сожалению, Вашего.
Благодарим за сотрудничество.
кстати, как там дела? Давно они поднялись? Как я понял, час с лишним пролежали… Или дольше?
У меня полтора часа.
Выше пишут что дольше.
Выше пишут что дольше.
Почему-то мне кажется, что многие российские компании просто вешают ярлык облачных сервисов на свои услуги, которые и ранее предоставлялись, только под другим ярлыком, забывая о нескольких основополагающих принципах, формирующих понятие облака.
По поводу ответа техподдержки — честно говоря, высочайшее проявление некомпетентности. Не знаю, с какого уровня это у них пошло, но гнать таких товарищей ссаными тряпками надо. Ишь ты, затронуло 10 клиентов всего, мы поэтому не будет писать в публичную ленту. Да даже если одного самого завалящего клиента затронуло — это уже информационный повод.
По поводу ответа техподдержки — честно говоря, высочайшее проявление некомпетентности. Не знаю, с какого уровня это у них пошло, но гнать таких товарищей ссаными тряпками надо. Ишь ты, затронуло 10 клиентов всего, мы поэтому не будет писать в публичную ленту. Да даже если одного самого завалящего клиента затронуло — это уже информационный повод.
> Почему о том что мой сервер не доступен я узнаю через полчаса по смс от Метрики. Почему не было рассылки по почте?
Настройте себе свой мониторинг и получайте sms через минуту недоступности. В чём проблема-то?
Настройте себе свой мониторинг и получайте sms через минуту недоступности. В чём проблема-то?
Прочитал топик, проверил свежесть бэкапов :-)
Memento mori :-)
Memento mori :-)
У меня есть небольшой кластер из 12 машин для проксирования популярной соц сети и, к счастью, со скалакси я его недавно разнес на несколько хостеров.
Давайте начнем с того, что на всеми любимом Западе проблемы аналогичны:
— Hetzner завалили по питанию две гермозоны. Кому-то пришло письмо? А дозвониться до саппорта пробовали?
— Амазон упал от удара молнии
Не спорю, что хабравчане имеют весьма обширный кругозор в IT. Но основная проблема непонимания одна: мы все говорим о разных вещах.
В свое время я этим очень сильно озадачился и доводил до исступления саппорт хостеров. Так что же такое настоящее облако?
Настоящее облако — это отсутствие единой точки отказа, и общий пул всех ресурсов:
— Сеть. Только VRRP, iBGP, BGP и несколько аплинков
— Вычислительные ноды. Только виртуализация и live migration. Если происходит аппаратный сбой на одной ноде, клиентские машины должны быть запущены на соседних. Есть реальная проблема: всего 10 нод, между 3 и 7 порвалась связь. Путем голосования, 3 ноды, должны на кворуме решить, что они в меньшинстве и освободить диски. Иначе, оставшиеся 7 при попытке запустить виртуальные машины, бывшие на этих трех, побьют файловую систему.
Что делать, если нода вышла из строя? Правильно, на кворуме назначается один ответственный и отправляет ноду в резет.
— Резервированный сторадж. Если честно, для меня загадка, почему скалакси упали месяца назад после ошибки инженера. Это значит что у них один сторадж — узкое горлышко без резервирования? Такая румба нам не нужна! Рейд поверх DRBD в мастер-слейве.
— Сеть для дисковых массивов. Только резервированные каналы на разных сетевых интерфейсах.
— Внутренняя сеть. Только тегированные пакеты и возможность создания устойчивых шифрованных туннелей.
— Ну и, естественно, стандартный API.
По крайней мере, именно так описали свое облако activecloud.ru и пока еще тьфу-тьфу причин для недоверия не было. А «извините, инженер Вася с похмелья вытащил первый и седьмой диск из массива вместо второго и четвертого и заморозил фс» — это какая-то отговорка.
Давайте начнем с того, что на всеми любимом Западе проблемы аналогичны:
— Hetzner завалили по питанию две гермозоны. Кому-то пришло письмо? А дозвониться до саппорта пробовали?
— Амазон упал от удара молнии
Не спорю, что хабравчане имеют весьма обширный кругозор в IT. Но основная проблема непонимания одна: мы все говорим о разных вещах.
В свое время я этим очень сильно озадачился и доводил до исступления саппорт хостеров. Так что же такое настоящее облако?
Настоящее облако — это отсутствие единой точки отказа, и общий пул всех ресурсов:
— Сеть. Только VRRP, iBGP, BGP и несколько аплинков
— Вычислительные ноды. Только виртуализация и live migration. Если происходит аппаратный сбой на одной ноде, клиентские машины должны быть запущены на соседних. Есть реальная проблема: всего 10 нод, между 3 и 7 порвалась связь. Путем голосования, 3 ноды, должны на кворуме решить, что они в меньшинстве и освободить диски. Иначе, оставшиеся 7 при попытке запустить виртуальные машины, бывшие на этих трех, побьют файловую систему.
Что делать, если нода вышла из строя? Правильно, на кворуме назначается один ответственный и отправляет ноду в резет.
— Резервированный сторадж. Если честно, для меня загадка, почему скалакси упали месяца назад после ошибки инженера. Это значит что у них один сторадж — узкое горлышко без резервирования? Такая румба нам не нужна! Рейд поверх DRBD в мастер-слейве.
— Сеть для дисковых массивов. Только резервированные каналы на разных сетевых интерфейсах.
— Внутренняя сеть. Только тегированные пакеты и возможность создания устойчивых шифрованных туннелей.
— Ну и, естественно, стандартный API.
По крайней мере, именно так описали свое облако activecloud.ru и пока еще тьфу-тьфу причин для недоверия не было. А «извините, инженер Вася с похмелья вытащил первый и седьмой диск из массива вместо второго и четвертого и заморозил фс» — это какая-то отговорка.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проблемы у Scalaxy