Comments 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 или по телефону, о том, что случилось и когда будет исправлено.
-26
Совковость вашего ответа over 9000
+22
Отличная позиция. Вы только что потеряли меня как клиента.
До свидания.
До свидания.
+16
Не одного, а много потенциальных клиентов.
+8
Я описал возможные способы получения информации о проблеме и сроках её решения, в случае с Оверсан-Скалакси на данный момент. Не вижу, где можно было интерпретировать мои слова по-другому и найти какую-либо позицию в отношении к Оверсан или пользователям облака, правда, простите.
-4
Внимательно посмотрел оный oversun.zendesk.com — не увидел сообщения.
+12
Да какая разница. Мне парсер их хелпдеска написать чтобы самому раз в полчаса не чекать? )
+8
Клиент: «Почему до сих пор нет сообщения в zenddesk о времени начала и продолжительности неработоспособности серверов (не только наших проектов, а вообще всех)?»
Контора: «Оповещение о недоступности серверов в облаке не было добавлено в публичный поток новостей, поскольку неполадки коснулись лишь небольшой части наших клиентов, в том числе, к сожалению, Вашего.»
Хорошо, конечно… но почему бы не оповещать эту «небольшую часть клиентов» в индивидуальном порядке, раз их число настолько ничтожно, что не стоит из-за этого «украшать» публичный поток?
Контора: «Оповещение о недоступности серверов в облаке не было добавлено в публичный поток новостей, поскольку неполадки коснулись лишь небольшой части наших клиентов, в том числе, к сожалению, Вашего.»
Хорошо, конечно… но почему бы не оповещать эту «небольшую часть клиентов» в индивидуальном порядке, раз их число настолько ничтожно, что не стоит из-за этого «украшать» публичный поток?
0
Что-то здесь не то… на дзендеске до сих пор ничего не появилось, или я не там смотрю?
Вам, Azy, ещё повезло… у нас так вообще один (из тех, что на оверсане) проект, судя по нагиосу, не откликался до 22:00.
Отдельные деньги, которые платятся за поддержку, а не за хостинг, тоже как-то на процесс «информирования клиентов» не повлияли. Плохо, товарищи… очень плохо! Оценка — неудовлетворительно!
Ответ хостера по данной проблеме:
Вчера у нас был сбой в облаке — несколько хостов виртуализации перешли в неработоспособное состояние и система мониторинга не оповестила администраторов (по ошибке, вообще такое оповещение всегда срабатывает). Поиск решения проблемы несколько затянулся, вдобавок к тому, что сама проблема была обнаружена не сразу. Сейчас необходимые новые уведомления в системе мониторинга добавлены и неприятностей такого характера больше не будет. (лир.отст. — это мы ещё посмотрим)
Процесс «поднятия» серверов с неработоспособных хостов виртуализации происходил в порядке, в котором они были расположены в БД Zen. Таким образом задержка ***.ru в какой-то степени связана с этим. Плюс к этому, сервер некоторое время находился в swap-е, в то время как сотрудники были уверены, что он еще не «поднялся» с неработоспособного хоста виртуализации на другом (новом) хосте. Надеемся, что такие недоразумения впредь происходить не будут.
Вам, Azy, ещё повезло… у нас так вообще один (из тех, что на оверсане) проект, судя по нагиосу, не откликался до 22:00.
Отдельные деньги, которые платятся за поддержку, а не за хостинг, тоже как-то на процесс «информирования клиентов» не повлияли. Плохо, товарищи… очень плохо! Оценка — неудовлетворительно!
Ответ хостера по данной проблеме:
Вчера у нас был сбой в облаке — несколько хостов виртуализации перешли в неработоспособное состояние и система мониторинга не оповестила администраторов (по ошибке, вообще такое оповещение всегда срабатывает). Поиск решения проблемы несколько затянулся, вдобавок к тому, что сама проблема была обнаружена не сразу. Сейчас необходимые новые уведомления в системе мониторинга добавлены и неприятностей такого характера больше не будет. (лир.отст. — это мы ещё посмотрим)
Процесс «поднятия» серверов с неработоспособных хостов виртуализации происходил в порядке, в котором они были расположены в БД Zen. Таким образом задержка ***.ru в какой-то степени связана с этим. Плюс к этому, сервер некоторое время находился в swap-е, в то время как сотрудники были уверены, что он еще не «поднялся» с неработоспособного хоста виртуализации на другом (новом) хосте. Надеемся, что такие недоразумения впредь происходить не будут.
+5
И у меня упало вчера очень неприятно. Хорошо вовремя увидел — какраз ковырялся в консоли… А ведь у меня там product-сервер. Для такого типа хостинга падения серверов — неприемлемо, но в два раза более неприемлемо — не информировать оперативно (минуты а не часы).
0
что-то не вижу я для себя перспектив переводить своих подопечных в облака… Ой, не вижу :(
За последний полгода таких новостей на главной все больше и больше.
Облако если падает, то все сразу.
А если один сервер из сотни клиентов упал, то остальным от этого вреда нет. И репутация — в порядке
За последний полгода таких новостей на главной все больше и больше.
Облако если падает, то все сразу.
А если один сервер из сотни клиентов упал, то остальным от этого вреда нет. И репутация — в порядке
+4
Я как человек, занимающийся оными вопросами (к Оверсану не имею никого отношения) могу сказать, что легенда, что «облака падают сразу и полностью» — неправда. В сколь-либо значительной конфигурации хосты всех (известных мне) гипервизоров и тулстеков обладают автономностью. То есть без панельки управления останетесь, без статистики и т.д, но виртуалка продолжит работать. Средняя консолидация «толстой виртуализации» (когда ядро в виртуалке у каждого своё) — около 1:40-1:70, то есть зависание одного хоста (его невозможно избежать, т.к. даже многобитовый ECC не даёт полной защиты от повреждения содержимого памяти всякой космической хренью) касается малого числа клиентов.
Падение СХД — хуже. Консолидация там выше (зависит от сложности и мощщи оной СХД), могу себе представить СХД, которая обслуживает пару тысяч виртуалок. Но опять же, в сколь-либо крупном облаке СХД обычно исчисляются десятками, если не стойками.
Таким образом, единственной «общей» точкой отказа может быть отказ электропитания в ДЦ (и другие проблемы «реального мира») — но они ровно так же ударят по любого рода размещению, будь то железный сервер или шаред хостинг.
В принципе, я могу представить себе отказ из-за фатального сбоя системы управления (например, добрый дядя сказал «выключить *» с консоли), но про такие случаи я как раз не слышал.
А все случаи, какие я слышал или наблюдал, всегда были связаны с отказом компонент — и тут я не вижу разницы с шаред хостингом или VDS.
А вот шуму это производит больше, потому что люди интуитивно ожидают от облаков совершенной надёжности (и небольшой даунтайм шаред хостинга воспринимают понимающе «ну, бывает», а такой же даунтайм машины в облаке — как вселенскую катастрофу)… А технологии FT (которые позволят сделать жизнь виртуалки более надёжной, чем жизнь хоста, на которой она работает) всё ещё находятся в состоянии deep research, и до продакта им далековато. Плюс, никто не обещал, что это будет так же дёшево и быстро.
Падение СХД — хуже. Консолидация там выше (зависит от сложности и мощщи оной СХД), могу себе представить СХД, которая обслуживает пару тысяч виртуалок. Но опять же, в сколь-либо крупном облаке СХД обычно исчисляются десятками, если не стойками.
Таким образом, единственной «общей» точкой отказа может быть отказ электропитания в ДЦ (и другие проблемы «реального мира») — но они ровно так же ударят по любого рода размещению, будь то железный сервер или шаред хостинг.
В принципе, я могу представить себе отказ из-за фатального сбоя системы управления (например, добрый дядя сказал «выключить *» с консоли), но про такие случаи я как раз не слышал.
А все случаи, какие я слышал или наблюдал, всегда были связаны с отказом компонент — и тут я не вижу разницы с шаред хостингом или VDS.
А вот шуму это производит больше, потому что люди интуитивно ожидают от облаков совершенной надёжности (и небольшой даунтайм шаред хостинга воспринимают понимающе «ну, бывает», а такой же даунтайм машины в облаке — как вселенскую катастрофу)… А технологии FT (которые позволят сделать жизнь виртуалки более надёжной, чем жизнь хоста, на которой она работает) всё ещё находятся в состоянии deep research, и до продакта им далековато. Плюс, никто не обещал, что это будет так же дёшево и быстро.
+10
amarao, я не совсем об этом.
наберите в поиске «Селектел»…
Два поста в блоге «негодую». По-моему, и третий был, когда были проблемы с восстановлением резервных копий (или с чем-то еще, я не особо слежу и радуюсь чужим неудачам, пусть и коллег по цеху).
То же самое можно и про Скалакси сказать. Про Амазон были вести, помните :-)
Это отнюдь не значит, что компании плохие.
Я вел лишь к тому, что падение инфраструктуры облака длится дольше и несет лучи горя для репутации компании больше, чем для обычного аппаратного «Хетцнероподобного» хостинга (назовем его «классическим»). Потому что «падают» все клиенты сразу. И жалуются тоже все сразу
Есть несколько тому причин. Основные проблемы хостинга какие? Оптику «автодоровцы» пересапали, свет отключили на неделю или друзья в погонах грабить пришли. Все решается относительно быстро: оптику ночью приезжает чинить сварщик по оптике за 2 см денег, мавр неспешно подливает бензин в дизель-генератор а «друзья» пьют чай в кабинете директора.
Это аппаратные проблемы. Есть еще и особый случай, когда один конкретный сервер одного конкретного клиента упал. Так он — один, клиент. А их — еще сотни довольных. Да и у этого клиента еще 4 рабочих сервера в нашем же ДЦ стоят и жужжат. В результате, он погорюет, посчитает простой, вздохнет, и будет дальше ждать восстановления работоспособности. Никто нигде не ругается, никто не валит из компании табунов в 4 десятка серверов. Все довольны.
Вы правы, падение облака шуму производит больше. И не потому, что люди интуитивно ожидают больше надежности (все везде относительно одинаково в рамках одной ценовой категории). В облачном хостинге появляется дополнительное слабое звено — его инфраструктура (совокупность п/о, идей и технологий), которая, как ни крути, не идеальна. И, к тому же, тянет всю компанию вниз, вместе с седеющими маркетологами, если не дай Б.г что случается.
В отличие от «обычного» хостинга.
наберите в поиске «Селектел»…
Два поста в блоге «негодую». По-моему, и третий был, когда были проблемы с восстановлением резервных копий (или с чем-то еще, я не особо слежу и радуюсь чужим неудачам, пусть и коллег по цеху).
То же самое можно и про Скалакси сказать. Про Амазон были вести, помните :-)
Это отнюдь не значит, что компании плохие.
Я вел лишь к тому, что падение инфраструктуры облака длится дольше и несет лучи горя для репутации компании больше, чем для обычного аппаратного «Хетцнероподобного» хостинга (назовем его «классическим»). Потому что «падают» все клиенты сразу. И жалуются тоже все сразу
Есть несколько тому причин. Основные проблемы хостинга какие? Оптику «автодоровцы» пересапали, свет отключили на неделю или друзья в погонах грабить пришли. Все решается относительно быстро: оптику ночью приезжает чинить сварщик по оптике за 2 см денег, мавр неспешно подливает бензин в дизель-генератор а «друзья» пьют чай в кабинете директора.
Это аппаратные проблемы. Есть еще и особый случай, когда один конкретный сервер одного конкретного клиента упал. Так он — один, клиент. А их — еще сотни довольных. Да и у этого клиента еще 4 рабочих сервера в нашем же ДЦ стоят и жужжат. В результате, он погорюет, посчитает простой, вздохнет, и будет дальше ждать восстановления работоспособности. Никто нигде не ругается, никто не валит из компании табунов в 4 десятка серверов. Все довольны.
Вы правы, падение облака шуму производит больше. И не потому, что люди интуитивно ожидают больше надежности (все везде относительно одинаково в рамках одной ценовой категории). В облачном хостинге появляется дополнительное слабое звено — его инфраструктура (совокупность п/о, идей и технологий), которая, как ни крути, не идеальна. И, к тому же, тянет всю компанию вниз, вместе с седеющими маркетологами, если не дай Б.г что случается.
В отличие от «обычного» хостинга.
+2
в отличие от «облачного», простите. 5erg, иди спать…
0
Я прекрасно понимаю разницу между «железным сервером» и любого рода сложными сервисами. Разумеется, сервисы накладывают дополнительный оверхед на 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 и облака одинаково по времени починки и даунтайму.
+5
Не соглашусь. Мало где шаред хостинг завязан на центральную СХД — дешевле локальные диски в софтмиррор собрать, да бэкапить периодически. Юзерам для фпт/ssh доступа выдается IP конечного физического сервера. Централизованным у хостинга остается лишь сеть (и да, «поднимать» ее куда проще, хотя пример Яндекса и говорит об обратном)
+1
Товарищи с netapp'ом меня начинают убеждать. Я считал, что большинство наших конкурентов тоже используют сегментирование СХД, но, возможно, я ошибаюсь…
0
Большинство использует сегментирование из-за дешевезны такого подхода, одна полка с дисками от NetApp стоит как пяток ваших ящиков от Супермикры :)
Но бывают исключения:
habrahabr.ru/company/cloudone/blog/117481/
Мне интересно как организованы сети хранения у таких гигантов как Amazon, Google и Microsoft. Серверы они заказывают у ODM, а вот с системами хранения всё немного сложнее.
Но бывают исключения:
habrahabr.ru/company/cloudone/blog/117481/
Мне интересно как организованы сети хранения у таких гигантов как Amazon, Google и Microsoft. Серверы они заказывают у ODM, а вот с системами хранения всё немного сложнее.
0
UFO just landed and posted this here
Но опять же, в сколь-либо крупном облаке СХД обычно исчисляются десятками, если не стойками.
Зачем в ДЦ десятки СХД, неужели не хватит пары больших NetApp'ов, дублирующих друг дружку?
0
Да конечно хватит. К ним ещё 2-3 сервера с топовыми ксеонами и вуаля — облако готово (:
зы. На самом деле, у хранилок в облаке основная проблема в пропускной способности к ним. А всякие большие netapp'ы и clariion'ы о пропускной способности нисколько не заботятся. Потому и нужны целые стойки.
зы. На самом деле, у хранилок в облаке основная проблема в пропускной способности к ним. А всякие большие netapp'ы и clariion'ы о пропускной способности нисколько не заботятся. Потому и нужны целые стойки.
+1
Нет. Мы делали SAN на 10G, так вот я могу сказать, что у нас гигабит трафика на стор — редкость. И это при >10k IOPS. Сеть там совсем не является боттлнеком.
+3
UFO just landed and posted this here
Когда все яйца в одной корзине (на одной площадке), особой отказоучтойчивости куча СХД не даст, а вот гемморой с обслуживанием вполне возможен.
Впрочем, про пропускную способность я не подумал, спасибо за ответ! :)
Впрочем, про пропускную способность я не подумал, спасибо за ответ! :)
+1
А вот это, кстати, да, интересный вопрос. В этом контексте я могу согласиться «падает облако целиком». У нас предполагается довольно сильная независимость СХД друг от друга. А вот если закладываться на одно решение как single point. Но это явная глупость.
И даже если «толстый netapp». Он всегда один? Большое облако всё равно должно подразумевать сегментацию.
И даже если «толстый netapp». Он всегда один? Большое облако всё равно должно подразумевать сегментацию.
+2
UFO just landed and posted this here
То есть когда это всё рушится, рушится всё сразу? Понятно, ок, начинаю думать, что миф может быть и не таким уж мифом.
Использовать единственную конструкцию для всего облака — ужас. Такое допустимо для management-интерфейсов, но никак не для инфраструктурных компонент.
Использовать единственную конструкцию для всего облака — ужас. Такое допустимо для management-интерфейсов, но никак не для инфраструктурных компонент.
+1
UFO just landed and posted this here
UFO just landed and posted this here
А напротив пример гугля, который не использует single point of storage.
0
Давайте переформулирую обратно: в ПО для фейловера нет ошибок? Ни одного бага?
0
UFO just landed and posted this here
Ну, не могу сказать, что щупал руками, но да, читал.
А ещё я лично наблюдал баги в IOS'е, которые приводили к исчезновению трансляции nat'а. Оно, конечно, с VRRP не связано, но иллюстрирует мысль, что теоретическая модель «как это делается» отличается от практической реализации, и не всегда в правильную сторону.
Выяснять, что у нас «не то отреплицировалось» или узел стал мастером с outdated копией данных при более актуальной копии на других узлах — будет крайне неприятно. И степень неприятности прямо пропорциональна тому проценту инфраструктуры, который завязан на эту неприятность.
Таким образом, сегментирование — очевидный (хотя и ограниченный в возможностях) метод изоляции ошибок.
А ещё я лично наблюдал баги в IOS'е, которые приводили к исчезновению трансляции nat'а. Оно, конечно, с VRRP не связано, но иллюстрирует мысль, что теоретическая модель «как это делается» отличается от практической реализации, и не всегда в правильную сторону.
Выяснять, что у нас «не то отреплицировалось» или узел стал мастером с outdated копией данных при более актуальной копии на других узлах — будет крайне неприятно. И степень неприятности прямо пропорциональна тому проценту инфраструктуры, который завязан на эту неприятность.
Таким образом, сегментирование — очевидный (хотя и ограниченный в возможностях) метод изоляции ошибок.
0
UFO just landed and posted this here
Пользуйтесь зарубежными вариантами вроде Amazon — и будем вам счастье.
-7
Ну, в общем-то да, русские «облака» — это тот же русский хостинг, только в профиль.
Есть же Amazon и ему подобные, зачем подвергать себя таким мучениям доверяясь русскому хостеру?
Есть же Amazon и ему подобные, зачем подвергать себя таким мучениям доверяясь русскому хостеру?
-5
«Облака» — это значит, «будет падать», по определению самого облака. Смысл облаков в том, что вы можете взять жменьку серверов, организовать из их отказоустойчевый кластер и выход из строя одной из нод (нескольких) вам будет по ключу.
Если вы используете «облака», как vps — ваш fail.
Если вы используете «облака», как vps — ваш fail.
+17
разумный комментарий
+4
разрешите подписаться!
+3
А мне всегда казалось, что облако — это платформа для разработики приложений (AWS, Azure, GAE) с офигительным SLA.
Но стараниями рекламщиков под облаками теперь понимают VPS с возможностью динамического раширения.
Но стараниями рекламщиков под облаками теперь понимают VPS с возможностью динамического раширения.
+2
Sorry, не понял ваш комментарий AWS у вас с одной стороны платформа для разработки приложений и облако. С другой стороны AWS (EC2, EBS, VPC) это те сами VPS-ки с возможностью динамического, в том числе автоматического, расширения.
Вы сами не запутались в том, что вы считаете облаком, а что нет?
Вы сами не запутались в том, что вы считаете облаком, а что нет?
0
Вы путаете IaaS и PaaS. Тут обсуждается IaaS. Там «надёжность получившегося» — ответственность пользователя, а поставщик должен лишь показатели SLA выдерживать (кстати, где вы там видели «офигительный SLA?»).
А вот что делать построением надёжных пользовательских конфигураций поверх PaaS — я не знаю. И вообще, считаю PaaS дурной затеей (в силу труднопроводимой линии отреза между «частью оператора» и «частью пользователя»).
ЗЫ Разумеется, я заинтересованное лицо и хвалю своё болото.
А вот что делать построением надёжных пользовательских конфигураций поверх PaaS — я не знаю. И вообще, считаю PaaS дурной затеей (в силу труднопроводимой линии отреза между «частью оператора» и «частью пользователя»).
ЗЫ Разумеется, я заинтересованное лицо и хвалю своё болото.
+1
И те и дургие сейчас называют облаками, даже SaaS туда иногда записывают.
По поводу PaaS всё довольно просто — провайдер предоставляет определённый API и сервисы с которыми работает разработчик, всё остальное (масштабирование, резервирование, обеспечение отказоустойчивости) является головной болью хостера. Преимущество такого подхода — прозрачное масштабирование, позволяющие уйти за пределы одного физического сервера (в случае IaaS придётся самому строить кластеры внутри инфраструктуры хостера).
По поводу PaaS всё довольно просто — провайдер предоставляет определённый API и сервисы с которыми работает разработчик, всё остальное (масштабирование, резервирование, обеспечение отказоустойчивости) является головной болью хостера. Преимущество такого подхода — прозрачное масштабирование, позволяющие уйти за пределы одного физического сервера (в случае IaaS придётся самому строить кластеры внутри инфраструктуры хостера).
0
Я всё это понимаю, я не понимаю, каким образом это должно оказаться надёжнее, чем решение на базе ИааС.
0
В случае IaaS вам даётся ВМ в рамках которой вы сами обеспечивает фейловер, в случае PaaS этим занимается хостер у котого больше ресурсов для решения задачи.
0
… И вот тут-то мы и переходим к проблеме «у хостера конфиг навернулся — все клиенты сосут лапу». Не нравится мне это.
Разрезание стека по инфраструктуре — куда более логичная вещь, чем резка в application layer.
Разрезание стека по инфраструктуре — куда более логичная вещь, чем резка в application layer.
0
Подобная проблема равносильна выходу из строя ДЦ у обычного хостера, так что клиенты сосут лапу в любом случае.
0
Выход из строя ДЦ = перенос серверов (физически) в другой ДЦ.
А как вы собираетесь «физически» переносить похеренные сбойнувшей кластеризованной системой данные? Кроме того, у ДЦ обычно есть совершенно простое и ясное SLA по электричеству, кондиционированию и коннективити.
Ни один поставщик СХД не подписывает подобного в отношении ПО. Подвести вылетевший винт/плату — да, конечно. А вот чтобы на сохранность данных при переходных процессах фейловера — нет.
А как вы собираетесь «физически» переносить похеренные сбойнувшей кластеризованной системой данные? Кроме того, у ДЦ обычно есть совершенно простое и ясное SLA по электричеству, кондиционированию и коннективити.
Ни один поставщик СХД не подписывает подобного в отношении ПО. Подвести вылетевший винт/плату — да, конечно. А вот чтобы на сохранность данных при переходных процессах фейловера — нет.
0
по-моему, многие так и не поняли. клауд — не панацея от сбоев и не серебряная пуля.
хотите надежности — запустите две/три/etc копии своих серверов в других регионах, настройте правильный failover и живите счастливо. и да, амазон тоже падает, и сбои довольно часты. для рассылки используется rss.
хотите надежности — запустите две/три/etc копии своих серверов в других регионах, настройте правильный failover и живите счастливо. и да, амазон тоже падает, и сбои довольно часты. для рассылки используется rss.
+3
Мне, кажется, автор больше возмущен не падением «облака» (никто не застрахован), а тем, что такой (распиареный) серис как Scalaxy (а за ним компания Oversun) не может настроить нормальную систему уведомлений о проблемах для своих клиентов.
Мы так же используем их сервис и с технической точки зрения вопросов нет — все понятно, всё пока работает; и личный кабинет хороший, и графики рисуются. Но система уведомлений — твиттер и публичная страница на oversun.zendesk.com/home (ссылка на которую никоим образом не отображается на сайте, а есть только в личном кабинете), на которой до сих пор нет никаких данных о возникшей проблеме.
Ребят, 21 век на дворе — увас есть база почтовых адресов клиентов, ну сделайте скрипт рассылку о проблеме! Проблема не в том, что у вас упало. Среди нас такие же технари — у все всё ломается. Почините и будет снова всем счастье. Но напишите письмо, которое мы потом сможем показать начальству, что «да, о проблеме знаем, устраняем. как сделаем, напишем. всё».
Ну и ответ саппорта о вчерашней проблеме:
12-21 12:07 (MSK):
Здравствуйте, Владимир!
Оповещение о недоступности серверов в облаке не было добавлено в публичный поток новостей, поскольку неполадки коснулись лишь небольшой части наших клиентов, в том числе, к сожалению, Вашего.
Благодарим за сотрудничество.
Мы так же используем их сервис и с технической точки зрения вопросов нет — все понятно, всё пока работает; и личный кабинет хороший, и графики рисуются. Но система уведомлений — твиттер и публичная страница на oversun.zendesk.com/home (ссылка на которую никоим образом не отображается на сайте, а есть только в личном кабинете), на которой до сих пор нет никаких данных о возникшей проблеме.
Ребят, 21 век на дворе — увас есть база почтовых адресов клиентов, ну сделайте скрипт рассылку о проблеме! Проблема не в том, что у вас упало. Среди нас такие же технари — у все всё ломается. Почините и будет снова всем счастье. Но напишите письмо, которое мы потом сможем показать начальству, что «да, о проблеме знаем, устраняем. как сделаем, напишем. всё».
Ну и ответ саппорта о вчерашней проблеме:
12-21 12:07 (MSK):
Здравствуйте, Владимир!
Оповещение о недоступности серверов в облаке не было добавлено в публичный поток новостей, поскольку неполадки коснулись лишь небольшой части наших клиентов, в том числе, к сожалению, Вашего.
Благодарим за сотрудничество.
+9
кстати, как там дела? Давно они поднялись? Как я понял, час с лишним пролежали… Или дольше?
0
У меня полтора часа.
Выше пишут что дольше.
Выше пишут что дольше.
0
кстати, тебе еще раз спасибо :-)
Отчасти, благодаря тебе стартовала моя маленькая, но гордая хостинговая компания с капитализацией в 75к. USD, своим 10-гигабитным подключением, ордой довольный довольных клиентов и светлым будущим :-)
Как тебя отбалгодарить, мой друг? :-)
Отчасти, благодаря тебе стартовала моя маленькая, но гордая хостинговая компания с капитализацией в 75к. USD, своим 10-гигабитным подключением, ордой довольный довольных клиентов и светлым будущим :-)
Как тебя отбалгодарить, мой друг? :-)
-1
UFO just landed and posted this here
Почему-то мне кажется, что многие российские компании просто вешают ярлык облачных сервисов на свои услуги, которые и ранее предоставлялись, только под другим ярлыком, забывая о нескольких основополагающих принципах, формирующих понятие облака.
По поводу ответа техподдержки — честно говоря, высочайшее проявление некомпетентности. Не знаю, с какого уровня это у них пошло, но гнать таких товарищей ссаными тряпками надо. Ишь ты, затронуло 10 клиентов всего, мы поэтому не будет писать в публичную ленту. Да даже если одного самого завалящего клиента затронуло — это уже информационный повод.
По поводу ответа техподдержки — честно говоря, высочайшее проявление некомпетентности. Не знаю, с какого уровня это у них пошло, но гнать таких товарищей ссаными тряпками надо. Ишь ты, затронуло 10 клиентов всего, мы поэтому не будет писать в публичную ленту. Да даже если одного самого завалящего клиента затронуло — это уже информационный повод.
0
> Почему о том что мой сервер не доступен я узнаю через полчаса по смс от Метрики. Почему не было рассылки по почте?
Настройте себе свой мониторинг и получайте sms через минуту недоступности. В чём проблема-то?
Настройте себе свой мониторинг и получайте sms через минуту недоступности. В чём проблема-то?
0
Прочитал топик, проверил свежесть бэкапов :-)
Memento mori :-)
Memento mori :-)
0
У меня есть небольшой кластер из 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 и пока еще тьфу-тьфу причин для недоверия не было. А «извините, инженер Вася с похмелья вытащил первый и седьмой диск из массива вместо второго и четвертого и заморозил фс» — это какая-то отговорка.
+3
Sign up to leave a comment.
Проблемы у Scalaxy