Комментарии 13
Использую Селектел и Амазон, доверяю только себе — делаю бекапы и резервирую машины.
А вопрос к вам простой: к чему все это?
А вопрос к вам простой: к чему все это?
Спасибо за ответ.
«Это» — это что? Публикация вот этой подборки про облака? Нам просто показались интересными эти факты и мы решили ими поделиться с окружающими. Многие в нашей компании, например, даже не задумывались о том, как и насколько часто падают «большие» облака.
«Это» — это что? Публикация вот этой подборки про облака? Нам просто показались интересными эти факты и мы решили ими поделиться с окружающими. Многие в нашей компании, например, даже не задумывались о том, как и насколько часто падают «большие» облака.
«Это» это этот пост. Делиться с окружающими фейлами других это странно.
Проскочила мысль «а не аналитику ли по падениям вы затеяли».
Проскочила мысль «а не аналитику ли по падениям вы затеяли».
Ну если бы мы писали об отказах именно оборудования, причем с указанием марок — согласны, это было бы не то чтобы странно, а некорректно и очень некрасиво. А в данном случае это просто подборка фактов. Учитывая, что мы предлагаем решения и для облаков — нам смысла нет пытаться выставить их в порочном свете, если вы об этом.
Полноценную широкомасштабную аналитику по падениям было бы очень интересно получить, но увы — это требует изрядного вложения времени и сил и не входит в наши планы.
Полноценную широкомасштабную аналитику по падениям было бы очень интересно получить, но увы — это требует изрядного вложения времени и сил и не входит в наши планы.
Не в марке оборудования дело. В порочном свете вы уже выставили кого могли заметить. Непонятно пока только одно — что вы собираетесь для этих падающих облаков продавать.
Информация больше предупредительного толка… Что даже облака не всегда решают до селе существующие проблемы многих датацентров — с оборудованием, питанием да и халатностью порой(человеческим фактором). Так-же появляются ошибки нового типа — из-за сложных механизмов регуляции работы самого облака, вылезают на свет ошибки в ПО. Теперь это выражение не будет голословным заявлением на фоне подобной минимальной статистики.
Опять-же этот факт можно использовать при планировании своего отказоустойчивого сервиса :)
Никто тут никого не обвиняет, но почти все крупные облачные игроки побывали в дауне и тут есть над чем подумать.
Опять-же этот факт можно использовать при планировании своего отказоустойчивого сервиса :)
Никто тут никого не обвиняет, но почти все крупные облачные игроки побывали в дауне и тут есть над чем подумать.
Правило админа номер 1 — не бывает надежных систем. Любая система может сломаться. Та, что сломаться не может теоретически — сломается тоже (например — PDU). Посему:
— бэкап всего что важно.
— бэкап НЕ там где сервер. Чем дальше — тем лучше.
— проверка целостности бэкапа (они, блин, ломаются!)
— план восстановления. Что, как, в какой последовательности. И не надо его держать там, где бэкапливаемое лежит.
Простые истины, которые спасают просто прорву свободного времени и сил
— бэкап всего что важно.
— бэкап НЕ там где сервер. Чем дальше — тем лучше.
— проверка целостности бэкапа (они, блин, ломаются!)
— план восстановления. Что, как, в какой последовательности. И не надо его держать там, где бэкапливаемое лежит.
Простые истины, которые спасают просто прорву свободного времени и сил
Ох, как же вы правы. Еще бы это понимали админы ))
А вот интересно — насколько спасает полное минимум двойное геораспределенное дублирование всех систем.
Чтобы вот допустим мой файл, лежащий в в двух разных физических ДЦ бекапился в двух разных местах — считаем что второго ДЦ нет, и в случае форс-мажора меня, как конечного пользователя должна мало волновать архитектура ЦОДов.
Вот меня сейчас мало волнует архитектура SkyDrive — я знаю что нужные мне файлики лежат минимум на всех моих машинах, которые к нему подключены + Azure — т.е. фактически чтобы пролюбить информацию надо уничтожить как минимум все устройства, доступ к которым у меня есть + найти спрятанный бекап (а он один? и в одном ли месте?) и уничтожить их
Чтобы вот допустим мой файл, лежащий в в двух разных физических ДЦ бекапился в двух разных местах — считаем что второго ДЦ нет, и в случае форс-мажора меня, как конечного пользователя должна мало волновать архитектура ЦОДов.
Вот меня сейчас мало волнует архитектура SkyDrive — я знаю что нужные мне файлики лежат минимум на всех моих машинах, которые к нему подключены + Azure — т.е. фактически чтобы пролюбить информацию надо уничтожить как минимум все устройства, доступ к которым у меня есть + найти спрятанный бекап (а он один? и в одном ли месте?) и уничтожить их
Ну вон печальный пример Google показал, что э-э-э софтверные ошибки способны свести к нулю одновременно любое количество копий. Если рассматривать в максимально широком плане защищенность от сбоев, то в идеальной системе должны дублироваться все подсистемы: ресурсы (вычислительная мощность, накопители), каналы передачи данных, управляющие модули (балансеры, супервайзеры и тому подобное).
Идеальным случаем хранения данных является, конечно, геораспределенное дублирование (крайне желательно три копии минимум) с регулярной проверкой состояния бекапа и хранением копии в отключенном состоянии для защиты от софтовых сбоев.
Идеальным случаем хранения данных является, конечно, геораспределенное дублирование (крайне желательно три копии минимум) с регулярной проверкой состояния бекапа и хранением копии в отключенном состоянии для защиты от софтовых сбоев.
из-за проблем с коммуникаторами начался комплексный сбойfacepalm просто… и вы железо продаете?..
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Падения облаков