Comments 177
Коллеги, спасибо за самоотверженный труд и честный разбор произошедшего.
Минутку. По данным мониторинга (WEBO Pulsar) мой облачный сервер ушел в даун 24 числа в 22:08, а стабильно оклемался только 25 числа в 23:14, что составляет более 25 часов даунтайма, что по SLA ведет к 90% компенсации. Ваше «округление» срезает 40% компенсации.
В облаке вам предоставляется инфраструктура, именно ее работа и имеется ввиду. Если какие-то отдельные машины не сразу запустились — тут уже проблема на стороне клиента. А то так можно машину еще пару суток не запускать и просить за это компенсацию…
Машина не потребовала от меня никаких действий и запустилась автоматически, поэтому я никак не мог ни ускорить ее запуск, ни препятстовать ему.
Интересное замечание, но вот только о возможности запуска никто-никого не уведомил и инструкцию не прислал (а там многие машины требовалось пропинать перед запуском через консоль).
А для того, чтобы понять процедуру (запуск с другого ядра, выполнения ряда комманд), приходилось писать в саппорт и ждать ответа.
А для того, чтобы понять процедуру (запуск с другого ядра, выполнения ряда комманд), приходилось писать в саппорт и ждать ответа.
IaaS. Предполагается, что вы знаете, как работать с серверами. Я целенаправленно веду к тому, чтобы облачный сервер был максимально похож на железный.
Напишите, пожалуйста, в поддержку через тикет-систему, возможно у вас компенсация будет выше. Ситуации могут быть разными, всё будет рассмотрено индивидуально. В статье указаны только те данные по компенсациям, которые относятся к большинству клиентов.
2е падение с компенсацией за кажется менее чем 2 месяца тестирования для своих нужд облачного сервера в #selectel. Подумал ещё и решил, что рановато мне пока в облака, отправился на VDS.
Но спасибо за описание, думаю светлое future ещё предстоит :)
Но спасибо за описание, думаю светлое future ещё предстоит :)
А как VDS может спасти от подобной проблемы с сетью?
Никак само собой, просто наблюдения за clodo и selectel как бы намекают, что пока не очень хорошо отлажены процессы и невысока надежность. В данном случае проблемы были ниже, но чаще софт и организация системы видимо приводят к нестабильности.
С VDS процессы и системы просто лучше отработаны, они как дебиан на фоне других линуксов в сравнении с облаками :)
С VDS процессы и системы просто лучше отработаны, они как дебиан на фоне других линуксов в сравнении с облаками :)
Если честно, не вижу разницы кроме той, что в большинстве реализаций VDS мне не гарантированы те ресурсы которые я потребляю или же у меня их переизбыток за который я плачу. У парней из Сlodo и Selectel получилось сделать тот же самый VDS, только более честный. Учитывая тот факт, что Selectel вот-вот закончит свою модернизацию, то надежность должна вырасти. Москва ведь тоже не сразу строилась. Я видел очень много разношерстного железа, на которых крутятся VDS-ы у зарекомендоваших себя хостерах и сравниваю с тем, на чем крутятся облака у Selectel и Clodo. У первых встречаются даже Desktop решения с древнейшими цисками. Предпочтение отдаю тому, у которого есть собственные ДЦ т.к. чувствую, что прогресс сдесь будет развиваться быстрее.
*здесь
Поддерживаю. В Selectel больше уверенности чем в clodo. Да и производительность (виртуальная, если можно так выразиться) у них выше. Тестировал на hlds-ах Counter-Strike 1.6, fps-а (игрового сервера) на виртуалках Selectel-а ощутимо больше. На clodo и вовсе фризы бывают по паре секунд. Единственное что очень досадно — нет облака Selectel в Москве. Я понимаю, что для сайтиков это совсем не критично, но когда каждые 5мс сетевой задержки конкурентное преимущество… Это грустно. Очень жду облако в московских ДЦ, но ни кто внятной информации об этом не дает. Оно и понятно, не может же быть двух amaramo, или не будет же кататься amarao из Москвы в Питер :) И да, в облаке Selectel можно запуститься на своем кастомном ядре, чего невозможно сделать в clodo. У меня конечно еще не получилось, то ТП утверждает что да, таки можно :) Молодцы!
Для развёртывания облака физическое присутствие не нужно.
Мы сначала закончим все переходные процессы тут, и только потом в МСК.
Мы сначала закончим все переходные процессы тут, и только потом в МСК.
Т.е. в планах железно есть и это лишь вопрос времени? Если да, то назовите хотя бы приблизительные сроки, хочу жить с надеждой :)
Сроков нет, надежда есть =)
Тут скорее всего решающим фактором станет целесообразность вложения средств в модернизацию инфраструктуры московского дата-центра, закупки оборудования для резервирования. Также необходимость выделить нужные емкости оптических волокон. Может даже построить резервную оптическую линию. Подведение необходимого канала связи, закупка трафика у вышестоящего оператора и т.д. Все это немалые вложения, которые должны окупиться хотя бы за 3 года. Не думаю, что открытие облака в Москве приведет массу новых клиентов. Скорее всего это будет расширение услуги для уже существующих, вряд ли на первом этапе можно ожидать резкого повышения оборота. Именно поэтому, может остаться только надежда.
Хорошо, что рассказали.
Жаль, из пяти облачных систем (Почти все на разных акках и созданы в разное время) одна сдохла напроч, на паре пришлось делать фсчк, на одной обошлось фсчк через ресью ядро.
Все мои клиенты, которых я давно уболтал перехать в облако, от вас к сожалению уйдут. С надежностью у вас какой-то ад.
Страно что проблемы с коммутатором и проводом привели к насмерть убитым файловым системам почти во всех случаях.
Все мои клиенты, которых я давно уболтал перехать в облако, от вас к сожалению уйдут. С надежностью у вас какой-то ад.
Страно что проблемы с коммутатором и проводом привели к насмерть убитым файловым системам почти во всех случаях.
Связь коммутаторов и СХД описана в статье, прочитайте внимательнее.
Мне это мракобесье будет тяжело обьяснить своим питерским клиенам.
Все было бы ничего (Даунтайм в пол дня можно забыть, тем более уже не первый раз такое) если бы на одном сервере не гакнулась файловая система с потерей почти всех данных.
Все было бы ничего (Даунтайм в пол дня можно забыть, тем более уже не первый раз такое) если бы на одном сервере не гакнулась файловая система с потерей почти всех данных.
К сожалению, от потери данных не застрахован никто, резервное копирование стоит выполнять даже на самых надежных серверах.
Да вы правы, но в таких случаях всегда ругают почему-то хостера.
Может быть в вашем случае будут ругать парня с пневматикой :)
Может быть в вашем случае будут ругать парня с пневматикой :)
Лучше поругать себя и для бизнес-критикал систем настраивать резервирование целых серверов с распределением по нескольким ДЦ.
Любое повышение надежности инфраструктуры ведет за собой повышение цен на ее ресурсы. Уверен, что если в Селектел придет человек и скажет, что мне нужна облачная инфраструктура с очень серьезным резервированием всего и распределением по дата-центрам, то ценник за ресурсы будет совсем иной. А когда есть люди, которые платят 200 рублей в месяц за облачной VDS и при его падении поднимают ор в твитере в стиле «Я теряю миллионы» не позаботившись при этом о его бэкапе, то вряд ли им это будет вообще интересно. Больше денег они все равно не заплатят.
Всё верно, приятно знать, что есть люди, понимающие это.
Мы учли ошибки, сделанные ранее. Новая СХД, с которой мы возились с июня, и в которой аварии на любом компоненте хранилища не приводят ни к чему, кроме 10-20с паузы в обслуживании (лагу) — и это в худшем случае. На цене iops/места оно не скажется (по крайней мере в течение ближайшего полугода — дальше заглядывать не могу).
Приятно слышать, мне очень нравится ваша платформа. И очень не нравится проблемы с фс клиентов после любых проблем на вашей стороне.
Новая СХД для старых облачных систем работает тоже, или надо пересоздавать сервер чтобы он получил новую СХД?
Новая СХД для старых облачных систем работает тоже, или надо пересоздавать сервер чтобы он получил новую СХД?
Особенно повеселили ребята с пневматами, такой неожиданный сюжетный поворот.
Админы поседели уже к девяти утра первого дня.
Да, вот интересно, их кормили эти сутки чем-нибудь? А поспать часик давали? :)
Поспать вряд-ли давали, разве что те моменты когда считали что проблема решена. :)
У нас были работы в понедельник в 7 часов. Я уехал домой и лёг спать в 21:00, в полночь меня разбудил инженер саппорта. Я поехал в Селектел (т.к. наша админка не работала в этот момент, а по Питеру в это время до Селектела ~12 минут езды), после сидел, готовился, писал простыни в notification, ждал, даже помогал вынимать 4200 из стойки.
хм… зачем-то мне включили вторую машину, которая была уже год как выключена и там ей и место.
второй сервер, включен, но не пингуется.
Точно все починили как следует?
второй сервер, включен, но не пингуется.
Точно все починили как следует?
Мои машины со вчерашнего вечера нормально работают.
Та, что включена но не пингуется — открывай консоль, наверняка диск просит fsck запустить.
Та, что включена но не пингуется — открывай консоль, наверняка диск просит fsck запустить.
да нет, ничего не просит.
Внутри машины тоже глухо как в танке
root@vm:~# ping ya.ru
ping: unknown host ya.ru
root@vm:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
^C
— 8.8.8.8 ping statistics —
78 packets transmitted, 0 received, 100% packet loss, time 76999ms
*это из консоли в панели управления
Внутри машины тоже глухо как в танке
root@vm:~# ping ya.ru
ping: unknown host ya.ru
root@vm:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
^C
— 8.8.8.8 ping statistics —
78 packets transmitted, 0 received, 100% packet loss, time 76999ms
*это из консоли в панели управления
Из-за массовости процесса алгоритм обнаружения «должна быть включена» довольно хитрый. Возможно, запустили ошибочно.
Для «не пингуется» — 99.9%, что fsck хочет проверку. Для машин эта авария была эквивалентна обыкновенному отключению по питанию.
Для «не пингуется» — 99.9%, что fsck хочет проверку. Для машин эта авария была эквивалентна обыкновенному отключению по питанию.
Очень радуют такие подробные описания проблем. Действительно ситуация нештатная, но как бы там нибыло даунтайм есть даунтайм. Лично у меня сервер на linode уже поднят. Часть проектов переношу туда, а часть оставляю тут, дабы всегда иметь возможность быстро перебросить сайты с одного сервера на другой.
А вообще, вам неплохо было бы нанять человека для анализа и контроля рисков. Пусть этот человек анализирует где «дракоша» попробует совершить очередную попытку суицида. Только не нужно воспринимать эту рекомендацию, как «возьмите козла отпущения».
Искренне желаю вам и вашим клиентам вечного аптайма;-)
А вообще, вам неплохо было бы нанять человека для анализа и контроля рисков. Пусть этот человек анализирует где «дракоша» попробует совершить очередную попытку суицида. Только не нужно воспринимать эту рекомендацию, как «возьмите козла отпущения».
Искренне желаю вам и вашим клиентам вечного аптайма;-)
UFO just landed and posted this here
UFO just landed and posted this here
Предлагаю завести хаб «Селектел упал», чтобы от него отписаться
Попробую напрячься и организовать. Не хаб, а отсутствие таких проблем. С этой аварией нас поймали на самом сложном моменте. С 27ого (с этой ночи) начинаются массовые переносы клиентов на новые сторы, там никаких багов mpt2sas, ixgbe, aacraid, linux-raid и т.д. не будет.
Звучит слишком самоуверенно, для системы состоящей из десятков сложных сервисов работающих вместе. Я вот никогда не даю таких гарантий даже для единичных сервисов — досконально проверить все просто невозможно.
а процесс переноса будет прозрачный, или будут сервера отключать?
Будут отключать, о чем amarao писал выше. Xen и сопутствующие либо еще не узнали о svmotion, либо не смогли сделать аналог.
Так как оно между друг другом никак не совместимо, то перенос будет делаться банальным sparse_dd, который, увы, требует выключения машины.
ndmp copy?
У XCP свой механизм копирования данных между SR'ами с правильным учётом дырок внутри VHD.
можно кстати использовать gzip ugzip через пайп, иногда эффективнее sparse_dd
Лучше я лишний раз это всё теребить не буду. Кроме того, gzip не оставит дырок в новом файле, а это плохо для (когда-нибудь починенных) снапшотов.
С учётом, что я двигаю кучу дисков (прям сейчас, кстати) — это не есть быть гут.
С учётом, что я двигаю кучу дисков (прям сейчас, кстати) — это не есть быть гут.
В файлах да, я же использовал это на блочных устройствах, там gzip соответственно записывал нужное количество нулей на выходном устройстве.
За описание спасибо.
Увы 3й раз за 2 месяца это слишком, переезжаю на AWS, у них замечательный бесплатный micro instance для небольших проектов и цены на spot instances очень радуют для проектов поболее…
Увы 3й раз за 2 месяца это слишком, переезжаю на AWS, у них замечательный бесплатный micro instance для небольших проектов и цены на spot instances очень радуют для проектов поболее…
> так как этот трансивер побывал в каждом из 3 коммутаторов
Не понял этот момент, как так?
На резервном коммутаторе не поставили необходимое число модулей и перевтыкали из основного?
Не понял этот момент, как так?
На резервном коммутаторе не поставили необходимое число модулей и перевтыкали из основного?
> Ускорение завершения работ по модернизации инфраструктуры облачных серверов.
О нет, только не это! Ну вы там не торопитесь особо, лучше уж наоборот не спешите, чем ускоряйте. Спешка она порой известно к чему приводит.
P.S.: обожаю такие статьи — что только на свете не бывает :)
О нет, только не это! Ну вы там не торопитесь особо, лучше уж наоборот не спешите, чем ускоряйте. Спешка она порой известно к чему приводит.
P.S.: обожаю такие статьи — что только на свете не бывает :)
Ускорение = перенос дисков в более принудительном порядке.
На ночь 27 (сегодня), 28, 29 уже всё расписано. Остальным придут уведомления за три дня до начала переноса.
Специально что-то форсироваться не будет — новая СХД в продакте с начала сентября, новые диски создаются там, на них уже больше 1000 дисков создано.
Единственный элемент форсирования — я хотел дать возможность людям выбрать самим диапазон времени переноски — но на кодирование и отладку этого нет времени, так что всех с 1 до 9 каждую ночь будем двигать.
ЗЫ Если кто наблюдал за бесконечными плашками вида «панель управления будет отключена» и т.д. — это как раз эти самые работы. Основная часть уже сделана — осталось только перенести клиентов.
На ночь 27 (сегодня), 28, 29 уже всё расписано. Остальным придут уведомления за три дня до начала переноса.
Специально что-то форсироваться не будет — новая СХД в продакте с начала сентября, новые диски создаются там, на них уже больше 1000 дисков создано.
Единственный элемент форсирования — я хотел дать возможность людям выбрать самим диапазон времени переноски — но на кодирование и отладку этого нет времени, так что всех с 1 до 9 каждую ночь будем двигать.
ЗЫ Если кто наблюдал за бесконечными плашками вида «панель управления будет отключена» и т.д. — это как раз эти самые работы. Основная часть уже сделана — осталось только перенести клиентов.
А компенсация будет начислена автоматически?
Задал этот вопрос через тикет-систему, сказали что да — автоматически в конце месяца.
Автоматически, но могут быть накладки. Компьютеру очень трудно объяснить, что запущенная машина — это сломанная машина, а машина, которая просто ребутнулась где-то сразу после аварии — рабочая.
Если к 10ому не будет компенсации за включенные машины, которые задело аварией — пишите тикет о том, что нет компенсации, их я вручную разбираю.
Если к 10ому не будет компенсации за включенные машины, которые задело аварией — пишите тикет о том, что нет компенсации, их я вручную разбираю.
Это такой высокобюджетный хоррор для айтишников, можно в кинотеатрах экранизацию показывать. А поворот со стрельбой вообще ад, на этом моменте сами зрители начинают немного подвисать.
Трансиверы «родные», или китайские аналоги?
Наверное «родные» — китайские
Уточню. Судя по:
1. приведенному вами сообщению в логах («Failed to read SFP+ ID EEPROM»);
2. по описанию подбора «рабочих» SFP;
3. по отсутствию упоминания общения с JTAC (за 24 часа можно было создать хотя бы 1 кейс)
проблема была в некачественных аналогах трансиверов.
1. приведенному вами сообщению в логах («Failed to read SFP+ ID EEPROM»);
2. по описанию подбора «рабочих» SFP;
3. по отсутствию упоминания общения с JTAC (за 24 часа можно было создать хотя бы 1 кейс)
проблема была в некачественных аналогах трансиверов.
Трансиверы не родные, но данный производитель использовался уже несколько лет.
С JTAC мы связались и получили две ответные реакции:
1. Трансивер не наш — идите лесом.
2. Реакция на сбойный трансивер (даже не их производства) не типична — создали кейс.
С JTAC мы связались и получили две ответные реакции:
1. Трансивер не наш — идите лесом.
2. Реакция на сбойный трансивер (даже не их производства) не типична — создали кейс.
Большое спасибо за прямой ответ!
Был подобный опыт с той же проблемой на неродных трансиверах: долго работало, внезапно перестало с той же ошибкой. Кейс закончился ничем.
Может, вам, кроме хронологии и защиты amarao все же попробовать в следующий раз прибегнуть к коллективному разуму? Спотыкались, как видите, не одни вы. Это просто предложение к размышлению.
Был подобный опыт с той же проблемой на неродных трансиверах: долго работало, внезапно перестало с той же ошибкой. Кейс закончился ничем.
Может, вам, кроме хронологии и защиты amarao все же попробовать в следующий раз прибегнуть к коллективному разуму? Спотыкались, как видите, не одни вы. Это просто предложение к размышлению.
А на чём ещё вы сэкономили?
Касательно ошибок «CM_TSUNAMI: i2c read on register (56) failed», а у вас есть подписка на их саппорт?
А компенсировать недоступность живых московских серверов из-за не отвечавших NS будете? :)
Недавно (до данной аварии) была рассылка с просьбой всем клиентам прописать все три наших NS сервера в СПб и МСК, если вам такой тикет не пришел, напишите, пожалуйста в саппорт.
Написал, с двух аккаунтов. Похоже, в обоих не было этого тикета.
Тикеты #106590 и #106589.
Тикеты #106590 и #106589.
Ну, собственно, чтд. Рассылка была, но она была не об ns-серверах, а о кэширующих DNS-серверах:
В ночь с 28 на 29 августа произошел сбой на одном из наших кэширующих DNS серверов (ip 188.93.16.19) повлекший за собой проблемы со связью на клиентских серверах. Сбой полностью устранен и предприняты меры для предотвращения повторных сбоев.
Для избежания подобных проблем просим Вас проверить сетевые настройки на Ваших серверах и указать в качестве DNS серверов все наши кэширующие серверы:
188.93.16.19
188.93.17.19
109.234.159.91
Также Вы можете использовать любые другие доступные DNS серверы.
Приносим извинения за доставленные неудобства.
Недоступность NS — это вообще самое страшное что может быть имхо, выучил урок после ддоса Zerigo.
У вас всего 3 сервера, для компании Вашего масштаба маловато, на мой взгляд.
У вас всего 3 сервера, для компании Вашего масштаба маловато, на мой взгляд.
Хм… всего 3? тогда у гугла всего 4 =(
Вместо язвительного остроумия положено говорить примерно следующее:
у нас три доменных имени для NS серверов, каждое из которых через раундробин отдает несколько юникастовых айпишников (причем сами записи хостятся не на этих серверах), суммарно NS серверов 84 штуки, каждый минимум на гигабитном канале, все разнесены географически на 12 независимых точек.
у нас три доменных имени для NS серверов, каждое из которых через раундробин отдает несколько юникастовых айпишников (причем сами записи хостятся не на этих серверах), суммарно NS серверов 84 штуки, каждый минимум на гигабитном канале, все разнесены географически на 12 независимых точек.
Такие проблемы решаются, если slave NS держать у другой компании, и в другом месте.
Знаете, я уже начинаю думать, что вы сами свои кабели обстреливаете, чтобы как-то оправдывать свой даун-тайм.
Но вот люблю я вас, с другими ещё хуже всё.
Но вот люблю я вас, с другими ещё хуже всё.
>После выезда аварийной бригады на место повреждения кабеля выяснилось, что кабель был обстрелян из пневматической >винтовки хулиганами, которых удалось задержать и передать в полицию.
Хулиганы всё это время ожидали аварийной бригады?
Хулиганы всё это время ожидали аварийной бригады?
Может быть есть какая-нибудь техническая возможность разделить #spb и #msk, по крайней мере для дедиков? Тогда в случае таких проблем, вони будет минимум меньше на одного клиента.
#spb и #msk разделены, каждый сегмент имеет свои независимые аплинки и является полностью автономным сегментом, но клиенты, которые обращались к московским серверам из питера пускались через наш линк спб-мск (поскольку иногда граничный маршрутизатор успевал прокидывать анонсы операторам в спб), а он в свою очередь терминировался на всё том же злополучном опорном коммутаторе…
Вымытый обстрелянный кабель с пулькой рядом — конечно верю.
На самом деле это наша попытка переложить на посторонних ответственность за 4ый из 7 случай падения сети. Разумеется, если нам удастся убедить общественность, что именно 4ый раз был результатом чьего-то хулиганства, то мы сможем заявить, что даунтайма не было и нам не надо будет признавать, что первые три до и все последующие — наша вина.
А вы нас разоблачили. На самом деле это тщательная имитация — ведь нам так важно было сокрыть один из 7 даунтаймов, что мы пошли на подкуп сотрудников милиции, наняли какого-то бомжа, чтобы стрельнул по кабелю, потом этот кабель вымыли и сфотографировали.
Так?
А вы нас разоблачили. На самом деле это тщательная имитация — ведь нам так важно было сокрыть один из 7 даунтаймов, что мы пошли на подкуп сотрудников милиции, наняли какого-то бомжа, чтобы стрельнул по кабелю, потом этот кабель вымыли и сфотографировали.
Так?
Да не важно, я уже не ваш клиент.
Сначала я вам радовался, потом вы меня огорчали, а потом и вовсе уничтожили мой HDD.
Ну а потом была мега-компенсация, 3.26 руб, уже и не помню, за какой именно простой.
Дошло до того, что я попросил удалить мою учетку, чтобы вы не слали мне свои уведомления. Однако, они все равно приходят, теперь уже сразу в спам.
Извините за язвительный комментарий про кабель, просто не смог пройти мимо этой фотографии. Очень жаль, что вы так резко упали.
Сначала я вам радовался, потом вы меня огорчали, а потом и вовсе уничтожили мой HDD.
Ну а потом была мега-компенсация, 3.26 руб, уже и не помню, за какой именно простой.
Дошло до того, что я попросил удалить мою учетку, чтобы вы не слали мне свои уведомления. Однако, они все равно приходят, теперь уже сразу в спам.
Извините за язвительный комментарий про кабель, просто не смог пройти мимо этой фотографии. Очень жаль, что вы так резко упали.
Спасибо за объективные комментарии. Компенсацию за мелкий даунтайм на несколько минут вы упомянули, а весьма значительную компенсацию за потерю данных — нет.
Весьма значительную — это сколько?
Напомните, пожалуйста.
Напомните, пожалуйста.
После чего на хабре появится комментарий о том, что мы делаем дисклоуз финансовых данных клиента. И мы будем долго и безутешно объяснять, как подумали, что некий ник на хабре равен нашему клиенту.
Если не возражаете про публикацию цифр финансовых данных, то нам требуется от вас тикет с указанием, что вы разрешаете нам на публично-доступных интернет ресурсах размещать информацию о зачисленных компенсациях с указанием длительности даунтайма по каждой и суммах месячного потребления облачных серверов.
Если не возражаете про публикацию цифр финансовых данных, то нам требуется от вас тикет с указанием, что вы разрешаете нам на публично-доступных интернет ресурсах размещать информацию о зачисленных компенсациях с указанием длительности даунтайма по каждой и суммах месячного потребления облачных серверов.
Я не могу зайти в панель — мой аккаунт удален.
Если не изменяет память, сумма там была до 300 рублей.
Так?
Если не изменяет память, сумма там была до 300 рублей.
Так?
Раз уж пошел такой разговор — я напоню еще, что вашу компенсацию можно потратить только на ваши же услуги.
Здесь остальной текст.
Согласно нашему соглашению об уровне услуг компенсация перечисляется на бонусный счет Заказчика и может использоваться только для оплаты потребления ресурсов виртуальными машинами клиента на серверах Исполнителя. Таким образом сумма компенсации не подлежит выводу с аккаунта.Здесь остальной текст.
Ну не верю я в такие совпадения. Обнаружил, что одна из машинок недоступна еще около 15 часов по Москве 24го. Ничем её доступность не мониторю, так что конкретнее сказать не могу. Как позже, по логам, выяснилось — машинка работала, была недоступна сеть(!!!). Времени разбираться не было. До вечера так и не поднялась, около 19 отписал тикет(#103528). Примерно через час пришел ответ, что поднимут после технических работ с сетевым оборудованием(!!!) ночью. Тут же написано, что проблемы начались вечером, с падения в 22. «Стрелки» затронули, опять же, как раз именно сеть. Странно это все…
По поводу компенсаций — это все, конечно, замечательно, но… В этом году мне пришла компенсация только за августовское падение и только за одну машинку (лежала не только она), за другие падения — ничего.
В общем, у меня 31 час даунтайма — сурово. Благо тестовые машинки и не особо важные сайты.
По поводу компенсаций — это все, конечно, замечательно, но… В этом году мне пришла компенсация только за августовское падение и только за одну машинку (лежала не только она), за другие падения — ничего.
В общем, у меня 31 час даунтайма — сурово. Благо тестовые машинки и не особо важные сайты.
Извините, вы прочитали написанную хронологию аварии? Она началась ночью 23его и длилась 24ого. Если у вас «всего лишь не было интернета» — значит машина была на новом хранилище.
Извините. У меня из-за работ собственная хронология съехала, выше комментарий неверный.
Парни, через эти проблемы пройдет любой хостер, который захочет выйти на этот рынок.
Потом у вас начнутся такие же проблемы со связностью отдельных ДЦ и availability зон. Но это естественно. Решайте проблемы и развивайтесь!
Потом у вас начнутся такие же проблемы со связностью отдельных ДЦ и availability зон. Но это естественно. Решайте проблемы и развивайтесь!
>Sep 24 22:02:02 chassism[903]: CM_TSUNAMI: i2c read on register (56) failed
Ну сразу же понятно, что проблема аппаратная.
Ну сразу же понятно, что проблема аппаратная.
все эти пертурбации навели меня на мысль что неплохо бы написать howto о том что делать во время и после аварии. ну там fsck, lvm как руками поднимать и проч.
оно конечно гуглится за пять минут, а ежели часто делаешь так и вообще в подкорку залезает, но как раз дело в том что слава богу нечасто надо это делать, а минуты эти — критичны.
оно конечно гуглится за пять минут, а ежели часто делаешь так и вообще в подкорку залезает, но как раз дело в том что слава богу нечасто надо это делать, а минуты эти — критичны.
> По итогам, было решено осуществить следующие мероприятия:
> 1. Усиленная проверка оптических трансиверов и сетевого оборудования в тестовом окружении;
А вариант поставить «родные» трансиверы на критических узлах не прошел?
> 1. Усиленная проверка оптических трансиверов и сетевого оборудования в тестовом окружении;
А вариант поставить «родные» трансиверы на критических узлах не прошел?
Наша задача — полностью исключить даунтаймы в будущем, а не написать в случае возникновения проблем в следующий раз «мы все делали правильно, во всем виноват Juniper/Cisco/Extreme или еще кто-то» — от этого никому легче не будет. Все-таки мы исходим из того, что надо обеспечивать надежность сети правильной архитектурой с внутренним резервированием, а не полагаться на отказоустойчивость отдельных компонентов (любое, даже самое надежное оборудование, может выйти из строя).
С учетом того что они делаются почти на одном заводе?)
Такое уместно только в одном случае: выполнить обязательные условия вендора чтобы исключить возможность отказа в поддержке. «Страховой случай» :)
В этот раз в новой версии JunOS в логах появились внятные сообщения и удалось найти жалобу на невозможность прочитать служебную информацию одного из SFP+ модулей,
Буквально весной, когда проходил обучение по джуносу инструктор несколько раз делал акцент на том, что с каждой новой версией джуноса служебные сообщения становятся все более читаемыми для простых смертных, ну и еще как бонус — загружается устройство с каждой новой версией всегда немного быстрее чем с предыдущей. Именно поэтому вопреки убеждению большинства «пока работает — не трогай» нам дали рекомендацию всегда обновляться на свежие версии JunOS. Не на последнюю, а на предпоследнюю версию (к примеру сейчас доступен 12.2R, значит девайсы надо держать на 12.1R), т.к. в совсем свежих могут быть неизвестные баги.
Ну и вопрос к представителям Селектела, меня этот момент очень смутил:
Неужели оборудование, которое установлено в критичных узлах не имеет контрактов на поддержку?
Проблема с которой вы столкнулись явно относиться к наивысшему приоритету Priority 1, Critical. Гарантированное время реакции — 1 час. Проблема не слишком сложная, так что ее бы решили очень быстро. Я уже не говорю о том, что в случае, если бы в течении 2-х часов не было решения, можно было бы эскалировать проблему руководителю службы технической поддержки, через 4 часа — вице-президенту, отвечающему за техническую поддержку и вице-президенту отвечающему за разработку.
JTAC имел право их послать из-за использования неоригинальных трансиверов.
Я видимо где-то не дочитал об этом… Тогда мне становится еще больше не понятна политика Селектела — в mission critical узлах использовать оборудование, которое официально не совместимо %)
«официально не совместимо» и «не совместимо официально» разные вещи ;)
Трансиверов-то по сути не так и мало нужно, и переплачивать 300% за оригинал не всегда кажется выгодным.
Особенно циско этим грешит, продают, скажем, за 200 баксов, а аналог, так сказать cisco-compatible, стоит 50.
Трансиверов-то по сути не так и мало нужно, и переплачивать 300% за оригинал не всегда кажется выгодным.
Особенно циско этим грешит, продают, скажем, за 200 баксов, а аналог, так сказать cisco-compatible, стоит 50.
Вам важнее экономия лишних 100-200 тыщ $$ или стабильность работы инфраструктуры и лояльность клиентов как текущих, так и будущих?
Хреновые трансиверы бывают у всех. Бывает и оригинальные Cisco страдают фигней, перегреваются и припаиваются к слоту, а «левые» OptiCin работают идеально.
Гарантий того что железка от вендора стабильна — нет.
Разве что саппорт пободрее.
Насколько я понял, не была обеспечено полноценное дублирование, а приходилось линки перевтыкать в резвервный коммутатор, что имхо не является дублированием.
Разве что саппорт пободрее.
Насколько я понял, не была обеспечено полноценное дублирование, а приходилось линки перевтыкать в резвервный коммутатор, что имхо не является дублированием.
Конечно, были обращения и в JTAC и общение с инженерами российского Juniper. Но проблема в том, что и те и другие могут что-то сказать и как-то помочь только на основании информации, предоставленной с нашей стороны. В описанных случаях в логах до обновления JunOS никакой конкретики не было. Как только в логах появилось сообщение о неисправности SFP+, то нам и самим стало ясно что нужно менять трансиверы — спустя 15 минут тоже самое подтвердили инженеры Juniper.
Что касается сервисных контрактов в целом, то опыт их использования скорее негативный (в том числе в одном партнерском проекте в котором на порядок больше оборудования по сравнению с сетью дата-центров Селектела). Одно время мы приобретали премиум контракты с 4-х часовой заменой оборудования в случае его неисправности вообще для всего сетевого оборудования, но по факту при всех неполадках поддержка оперативно помочь не могла, быстрее разбирались сами, и ни одна «4-х часовая» замена не прошла быстрее, чем за 12 часов (среднее время — 16 часов). Сеть смешанная Cisco/Juniper. Не думаю, что у других вендоров с этим как-то сильно лучше.
Что касается сервисных контрактов в целом, то опыт их использования скорее негативный (в том числе в одном партнерском проекте в котором на порядок больше оборудования по сравнению с сетью дата-центров Селектела). Одно время мы приобретали премиум контракты с 4-х часовой заменой оборудования в случае его неисправности вообще для всего сетевого оборудования, но по факту при всех неполадках поддержка оперативно помочь не могла, быстрее разбирались сами, и ни одна «4-х часовая» замена не прошла быстрее, чем за 12 часов (среднее время — 16 часов). Сеть смешанная Cisco/Juniper. Не думаю, что у других вендоров с этим как-то сильно лучше.
JTAC-y понадобилось ~10 часов (с момента первого сбоя в 22:00 до момента пока вы обновили JunOS — 8:44 следующего дня) что бы дать Вам рекомендацию обновить джунос? Они не смогли идентифицировать что проблема аппаратная и не зависит от конкретной железки пока вы не обновили джунос и сами не увидели явное сообщение, гласящее о том что проблема с SFP+ трансивером? Была ли эскалация на высшие уровни, раз обыкновенные инженеры не могли решить проблему?
Я это все к чему спрашиваю: мы планируем относительно небольшой проект на оборудовании от Juniper и хотелось бы знать насколько качество JTAC соответствует заявленному.
ЗЫ а можно версии JunOS (которая стояла изначально и на какую обновились)?
Я это все к чему спрашиваю: мы планируем относительно небольшой проект на оборудовании от Juniper и хотелось бы знать насколько качество JTAC соответствует заявленному.
ЗЫ а можно версии JunOS (которая стояла изначально и на какую обновились)?
Так а что мешает текущим трансиверам опять слететь? Этот вопрос как-то будет решаться, или мы просто ждем следуюего факапа с ними и быстро устраним неисправный?
А тем временем у меня пропала вся статистика использования дисков по серверу в облаке. Вобщем-то я уже съехал и по большому счету мне все равно, наводит на размышления…
Статистика не «съезжает», диски были перенесены на новое хранилище, у них новый uuid. Данные по старому uuid'у всё ещё есть, их не показывает панель. issue есть, так что в ближайшее время графики будут просто «суммироваться» о всем uuid'ам, связанным с машиной (т.е. будут показываться в прошлое вне зависимости от перерыва).
прям шедевр
Но! Пожалуйста! Сделайте наконец возможность менять пароль от аккаунта через HTTPS, а не методом пересылки его открытым текстом по почте.
Даже обидно, что пароль какого-нибудь субпользователя на хранилище можно сгенерировать и забрать по HTTPS, а главный пароль ОТ ВСЕГО просто так ходит по интернетам :(
Даже обидно, что пароль какого-нибудь субпользователя на хранилище можно сгенерировать и забрать по HTTPS, а главный пароль ОТ ВСЕГО просто так ходит по интернетам :(
Если у вас правильно настроен сервер, то почта будет ходить по шифрованному соединению между серверами.
А насчёт пользовательских паролей… Мы один раз разрешали пользователям давать пароль для машины при создании. Пришлось отказаться — слишком высокий процент квертизма там был.
А насчёт пользовательских паролей… Мы один раз разрешали пользователям давать пароль для машины при создании. Пришлось отказаться — слишком высокий процент квертизма там был.
Речь скорее про изменение пароля через вебформу — отправка данных вебформы идет без шифрования.
А, вы намекаете, что админская почта должна быть на своем правильно настроенном сервере?.. Это интересный point.
Алсо, задавать пароль самостоятельно необязательно, а вот забирать из админки по HTTPs — очень хорошо бы.
Алсо, задавать пароль самостоятельно необязательно, а вот забирать из админки по HTTPs — очень хорошо бы.
А теперь вопрос: как вы его будете восстанавливать, когда забудете?
Предыдущим способом — на почту, после чего сразу поменяю в админке.
Так работает большинство известных мне сервисов, плюс они форсят одноразовость того, что высылается на почту. По-моему, это принципиальный момент (все открытое — одноразовое), но с шифрованными каналами между почтовиками вы меня озадачили :)
И чем это отличается от отправки пароля? Если кто-то завладел вашей почтой — взлом аккаунта — вопрос времени. Если вы боитесь хранить пароль плейнтекстом в почте — сохраните в любимый password keeper и сотрите письмо. Если вы не доверяете почтовой службе, то она ваш аккаунт сломает, т.к. может перехватить письмо со ссылкой на сброс пароля.
То есть безопасности не добавляет — геморроя с хождением по ссылкам — да.
То есть безопасности не добавляет — геморроя с хождением по ссылкам — да.
Да, почта — это святое, считаем, что она моя.
Хранить не буду, сотру, да.
А вот в плане передачи в открытом виде, почтовой службе (и всем промежуточным узлам) — и впрямь не доверяю, также как и ОПСОСу, передающему SMS-ки.
Поэтому что почтой, что SMS-ками — стоит передавать только одноразовые и короткоживущие секреты.
Я не то что бы прям криптоаналитик, просто вижу, что подобная схема внедряется чуть менее, чем везде вокруг (веб-сервисы, банки).
Хранить не буду, сотру, да.
А вот в плане передачи в открытом виде, почтовой службе (и всем промежуточным узлам) — и впрямь не доверяю, также как и ОПСОСу, передающему SMS-ки.
Поэтому что почтой, что SMS-ками — стоит передавать только одноразовые и короткоживущие секреты.
Я не то что бы прям криптоаналитик, просто вижу, что подобная схема внедряется чуть менее, чем везде вокруг (веб-сервисы, банки).
Хех, и как вы думаете, сколько промежуточных узлов между вашим почтовым сервером и нашим? Отвечаю: 0. Наш сервер обращается по MX к вашему и передаёт почту.
Если же вы говорите про узлы сети, то…
en.wikipedia.org/wiki/STARTTLS
У меня ни разу в продакте не было почтового сервера, который бы не умел TLS.
Если же вы говорите про узлы сети, то…
en.wikipedia.org/wiki/STARTTLS
У меня ни разу в продакте не было почтового сервера, который бы не умел TLS.
Угу. Вобщем, при такой схеме никакое гмыло лучше не использовать (мало ли, что он там «удаляет», когда я его прошу), а хостить свою почту на своем сервере на своем домене. У другого, что ли, хостера? ;)
У меня мой «главный» ящик (для паролей, банк-клиентов и т.д.) на моей машине настроен. Тут я точно знаю весь flow от банка до меня.
Письмо же со ссылкой на сброс я открою в течение 1 минуты, после чего оно потеряет актуальность. Вероятность успешного перехвата — по-моему, мизерная, если разве кто-то в ней не начнет городить автоматику по перехвату парольных писем от популярных служб.
Sign up to leave a comment.
Неполадки в работе сервисов 24-25 сентября