Опять авария в облаке Selectel… Доколе?

[Mairon]

Пикачуamarao, я выбираю тебя!

[amarao]

Мне пришлось срочно дёргать программиста для реализации кода ручного снятия блокировки vdi. Проблема была именно в сочетании синхронного переключения на резервный узел, обновления данных во время сканирования и ребутящихся товарищей.

[stigger]

у меня сервер включен, виртуальная машина живая и доступна по ssh, но файловая система перемонтировалась в read only.

[stigger]

мне саппорт ответил через 15 минут, сказали перезагрузить машину из панели. после ручной починки файловой системы (она перемонтировалась в ro из-за проблем с блочномым устройством) всё завелось и сейчас вроде бы работает нормально.

[fortyseven]

Произошла задержка ввода/вывода на одном из хранилищ (данные не пострадали), проверьте состояние ВМ через консоль, возможно потребуется перемонтировать ФС или перезагрузить ВМ.

[silvergh0st]

Она даже не запускалась…

Сейчас проверил — висит в консоли с проблемой ФС. Запустил проверку.

[silvergh0st]

Не стартует после ребута снова.

[stigger]

когда я после проверки ФС написал reboot, система почему-то выключилась. на закладке «управление» включил — заработало.

[totalcount]

Техподдержка отвечает вот такое:
Здравствуйте. Случился программный сбой на СХД, из-за которого запросы ввода-вывода выполнялись с задержкой в несколько минут. Сейчас сбой устранен. Приносим извинения за неудобства.

[totalcount]

Машина ушла в ребут, и обратно не поднимается.

[fortyseven]

консоль?..

[totalcount]

Уже поднялось все.

[stigger]

посмотрите в консоль, скорее всего надо руками запустить fsck.

[silvergh0st]

та же проблема.
ТП мне так и не ответила.

[totalcount]

Из панели попробуйте включить, должно заработать.

[totalcount]

Вроде поднялось все.

[amarao]

Саппорт работает.

В кратце: упал один из узлов кластера СХД, по закону подлости в тот момент, когда происходило пересканирование SR (аккаунтинг снапшотов).

Итог: блокировка процесса, ручное снятие блокировки.

Последствия: порядка 10 минут IO lock для клиентов (выглядит как трейс вида

[112800.281512] INFO: task process_name:19189 blocked for more than 480 seconds.      
[112800.281514] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
 message.                                                                       
[112800.281517] proces_name          D 0014a870     0 19189      1 0x00000000        
[112800.281522]  d3cbdcf0 00000282 f659f223 0014a870 d3cbdccc d483e070 c0834f80 
c0834f80                                                                        
[112800.281531]  43ef9ebd 000065d3 d55b9f80 d3de6230 d483e070 d3cbdd0c c1d0e000 
d3cbdd30                                                                        
[112800.281540]  00000000 f682d39e 0014a870 f659f223 0014a870 c079dc80 00000000 
00627e90                                                                        
[112800.281549] Call Trace:                                                     
[112800.281553]  [<c04854c3>] io_schedule+0x73/0xb0                             
[112800.281557]  [<c0128e75>] sleep_on_buffer+0x5/0x10                          
[112800.281562]  [<c0485aaf>] __wait_on_bit_lock+0x3f/0x90                      
[112800.281567]  [<c0485b65>] out_of_line_wait_on_bit_lock+0x65/0x80            

Около 15 машин попытались ребутнуть, они наткнулись на блокировку (которую я руками снимал сейчас).

По сути: у большинства клиентов — лаг на несколько минут; у 15 машин — даунтайм (вместо ребута).

Сейчас должно было всё нормализоваться.

[stigger]

не просто лаг, а перемонтирование / в read-only. такое без ручного вмешательство само по себе не нормализуется.

[amarao]

Стоп. А вот это не ожиданное. Какие диски ушли в ro? У нас стоит режим error=panic, т.е. машина должна перезагружаться.

[stigger]

у меня только один диск к виртуальной машине подключен. uuid диска a7e90219-5a04-4eab-9703-08f7b8b51a39

вот лог:

INFO: task pdflush:170 blocked for more than 120 seconds.
end_request: I/O error, dev xvda, sector 4828123
Buffer I/O error on device dm-0, logical block 565313
lost page write due to I/O error on dm-0
Buffer I/O error on device dm-0, logical block 565314
lost page write due to I/O error on dm-0
end_request: I/O error, dev xvda, sector 4828171
Buffer I/O error on device dm-0, logical block 565319
lost page write due to I/O error on dm-0
Aborting journal on device dm-0.
ext3_abort called.
EXT3-fs error (device dm-0): ext3_journal_start_sb: Detected aborted journal
Remounting filesystem read-only
EXT3-fs error (device dm-0) in ext3_reserve_inode_write: Journal has aborted
EXT3-fs error (device dm-0) in ext3_reserve_inode_write: Journal has aborted
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data
......
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_committed_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data
journal commit I/O error

[amarao]

Возможно у нас ошибка в шаблоне. Если можно, содержимое fstab в приват. Заранее спасибо.

[silvergh0st]

ХЗ у кого оно там нормализовалось, а у меня даже ручной запуск fsck.ext4 /dev/xvda1, который сказал clean, не помог… Машина так и не поднимается.

[amarao]

номер тикета?

[silvergh0st]

82465

[amarao]

Не могу делать disclose, но от вас ожидается одна простая комбинация клавиш в консоли. Подробности в тикете.

[silvergh0st]

Неужто вы думаете, что я на столько глуп, чтоб не запустить автоматический чекинг?
Раз 5 делал… Толку нет. Потому и попробовал вручную.

[silvergh0st]

Запустил еще раз… Раз уж рекомендуете…

Результат:

[ 4.568994] EXT4-fs error (device dm-1): ext4_journal_start_sb:327: Detected
aborted journal
[ 4.569004] EXT4-fs (dm-1): Remounting filesystem read-only
[ 4.601277] Kernel panic — not syncing: EXT4-fs (device dm-1): panic forced a
fter error

[silvergh0st]

Может надо было на /dev/mapper/odin_system-root натравить fsck?

[bezumkin]

А меня в этот раз пронесло!
Метрика только один сайт из 8 на 2х серверах увидела нерабочим, на час. Сейчас все ок, никаких проблем.

Повезло.

Но тенденция регулярных падений, конечно, совершенно не радует. Неужели таки и вправду, нужно на Amazon за качеством ехать?

[datacompboy]

Амазон вообще не обещает аптайма.

[sck_v]

Но он его предоставляет

[datacompboy]

как человек, который амазон пользовал, скажу — там далеко не радужно.
и если виртуалка падает — амазон предлагает запустить новую.
диски надо? используйте persistent. ах, вы не подключали его? извините.
ах подключали, и не доступно? поднимайте snapshot.
ах, вы его не делали? извините, сами дураки.
ах, они не доступны? извините, или подождите и может станет доступным, или сами дураки что снапшоты не лили в другую зону.

[vimvim]

Очень плотно используем AWS больше года. За все время один раз была небольшая проблема с инстанцем, решилась простым перезапуском.
Как и в каждом сервисе есть best practice которых следует придерживаться. Для AWS это:
— Использовать EBS instances если Вам важны данные хранимые на сервере. Если данные временные ( например какие-то промежуточные данные для вычислений ), то можно обойтись instance storage.
— Периодически делать snapshots

На мой взгляд AWS предоставляет на данный момент самый стабильный и устойчивый сервис.

[vimvim]

Амазон гарантирует 99.95% uptime ( для EC2 ) в своем SLA: aws.amazon.com/ec2-sla/

[datacompboy]

Еще «Amazon EC2 SLA Exclusions» прочитайте. Когда 3 дня всё лежало от молнии — это всё нормально :)

[vimvim]

Нет, это не нормально и Амазон не расценивает этот случай как нормальный: aws.amazon.com/message/2329B7/
Да, конечно, в SLA Амазона ( как и любой другой компании ) есть пункт про форс мажор под который можно подвести и удар молнии, но в данном конкретном случае Amazon предоставил всем пострадавшим пользователям 10 day credit.
AWS обслуживает тысячи пользователей среди которых есть весьма серьезные организации. Если он не будет обеспечивать приемлемый уровень uptime, то в мгновение ока потеряет всех пользователей и кроме того может получить миллионные иски от пострадавших. Так же не стоит забывать что на AWS работает вся инфраструктура Amazon, а тут любой простой это коллосальные убытки, падение котировок и опять же иски ( на этот раз инвесторов). То есть все что касается uptime для AWS очень и очень серьезно и измеряется конкретными суммами со многими нулями.

[Bright]

Заголовок жутковатый :)

Насколько я понял, проблемы относятся больше к новому ЦОДу? У себя подобного не замечаю (расположение указано как «Санкт-Петербург (1)»).

[budulay]

Та да, старое облако уже больше как полгода не падает.
Хоть в новом есть свои плюшки, но пока туда переносить свою вм не хочу)

[kai]

Что-то у Скалакси давно проблем не было. Лажают. Надо быть начеку. А так по ходу дела надежный один Амазон, но за него юрик из РФ хрен заплатит официально ;(

[piroman]

Заплатит. Велкам ту валконтроль. С амазана трясти инвойсы и фактыры.

[vimvim]

Ну счет за услуги, допустим, можно получить прямо с сайта AWS.
Но ведь у нас хотят чтобы был:
— Договор с синей печатью и подписями ( оригинал )
— Счет с синей печатью и подписями ( оригинал )
— Акт выполненных работ с печатью и подписями
Лично для меня не представляется возможным получить с Amazon данные документы. По крайней мере если счета не превышают 6 значные суммы.

[piroman]

Вы еще не научились подделывать печати и подписи?
Кстати, печати на американских документах давно не синие, а выдавленые на блестящей наклейке.
Но в Москве делают и такие

Что бы тебе послали реальные документы, по моей практике, достаточно четыехзначных сумм. Шлют даже DHL прямо в офис. Правда, врать не буду, с Амазаном не было такой практики.

[FreeLSD]

амазон падал на сутки в том году.

[VasiliyIsaichkin]

Ну не весь же падал, а только одна из зон доступности, но не раз (то молния, то ошибка при восстановлении)

[FreeLSD]

Я ответил на фразу А так по ходу дела надежный один Амазон

вот этим habrahabr.ru/post/117933/
Надежность, близкую к 99.99% можно получить. Но вопрос в цене. Глупо ожидать за 1.000 рублей непадающий сервис. Вы бы знали сколько всего накручено у облака: железо, гипервизоры, управлялка, CLVM, ISCSI, DRBD, OpenStack и каждый элемент может дать отказ. Помимо того, что квалификация людей, работающих с этими системами, как правило, очень высокая. Это нестандартные сервисы, по которым мануалов куча. Практически все баги ловятся самостоятельно и просить помощи в расшифровке логов у гугла тяжело.
Амазон, кстати один из самыъх дорогих облаков, насколько я знаю.

[VasiliyIsaichkin]

Знаю сколько всего накручено, потому полностью согласен. Но все таки есть факт — надежность сейчас требуется на пару порядков выше — остается надеяться что все эти падения идут на пользу, нарабатывается опыт эксплуатации и оттачивается архитектура.

[amarao]

Оттачивается, оттачивается. Авария была на СХД с ~500 дисками клиентов, затронуто оказалось примерно 30 (часть обнаружилась чуть позже первого моего комментария). Остальные спокойно продолжили работать.

[Scalar]

Буквально на прошлой неделе мои виртуальные машины в Scalaxy упали и лежали пару часов. Потом поднялись, но в течении еще трех дней работали хуже некуда, как будто в сервер поставили 8086 и 640кб.
Хотел написать еще один топик, но было некогда.

[dev1ce]

Ох, ппц.
Такими темпами он скоро начнет выдавать простыню текста типа: Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y Cloud4Y.

[BarsMonster]

Не стоит по локальным проблемам делать глобальные выводы.

У моей виртуалки на селектеле аптайм уже 220 дней, ни одной проблемой меня не цепляло, т.к. проблемы все были в той или иной мере локальные.

[ngreduce]

Людей можно понять, им все равно что будет с другими виртуалками. Каждого волнует своя в. машина.

[silvergh0st]

Перенесли заметку в «Я негодую», а сделать UPD не хватает кармы.

UPD №5: Машина поднялась в час ночи по Киеву, но после проверки ФС тех. поддержкой пропал один файлик. Восстановить не затруднило ручками, но насторожило. Делайте бекапы! :)