Комментарии 22
А самого ценного совета — НЕ ХРАНИТЕ ВСЕ ДАННЫЕ В ОДНОМ ОБЛАКЕ так и не было.
Это должен быть первым советом перед всеми остальными, далее IaaC, далее мониторинг нагрузки и financial forecast — при работе в чужом облаке необходимо предсказывать расходы и иметь индикаторы позволяющие принять решение о миграции. Ну и конечно же не стоит выбирать те облака, в которых основная компания очень озабочена сбором максимума персональных данных о клиентах, кто скажет, что они и с бизнесклиентов аналитику не берут, а ещё в эти облака стоит заливать свои дистрибутивы, в которых не будет Амиго, Агента и Гварда, и прочих Spyware/Adware
Это должен быть первым советом перед всеми остальными, далее IaaC, далее мониторинг нагрузки и financial forecast — при работе в чужом облаке необходимо предсказывать расходы и иметь индикаторы позволяющие принять решение о миграции. Ну и конечно же не стоит выбирать те облака, в которых основная компания очень озабочена сбором максимума персональных данных о клиентах, кто скажет, что они и с бизнесклиентов аналитику не берут, а ещё в эти облака стоит заливать свои дистрибутивы, в которых не будет Амиго, Агента и Гварда, и прочих Spyware/Adware
Почему не надо хранить в 1 облаке? И как тогда хранить?
Займусь немного самоцитированием
Рассмотрение размещения информационных систем в облаке начинается с разработки методики выхода из облака в другое облако (или назад в собственный ЦОД).
Размещение информационной системы в облаке начинается с разработки схемы резервного копирования в контролируемую вами инфраструктуру.
habr.com/ru/post/513892
Рассмотрение размещения информационных систем в облаке начинается с разработки методики выхода из облака в другое облако (или назад в собственный ЦОД).
Размещение информационной системы в облаке начинается с разработки схемы резервного копирования в контролируемую вами инфраструктуру.
habr.com/ru/post/513892
Антон, не видел, спасибо за ссылку. Подтверждает накопленный опыт.
«НЕ ХРАНИТЕ ВСЕ ДАННЫЕ В ОДНОМ ОБЛАКЕ» как я понял калька с «Не храните все яйца в одной корзине», я думал имелось в веду не резервное хранилище, в именно хранить часть данных в 1 облаке, другую часть данных — в другом. Это глупо, на мой взгляд. Против хранения бекапов у себя или в другом облаке ничего не имею.
Смотрите какой интересный момент.
Предположим, что в вашей компании используется корпоративный дропбокс — это одно облако.
Еще используется salesforce (или любая другая облачная CRM) — это второе облако.
И еще office365 (и outlook.com) — это третье облако.
И еще Яндекс.Облако для IaaS — это четвертое облако.
Глупо?
Предположим, что в вашей компании используется корпоративный дропбокс — это одно облако.
Еще используется salesforce (или любая другая облачная CRM) — это второе облако.
И еще office365 (и outlook.com) — это третье облако.
И еще Яндекс.Облако для IaaS — это четвертое облако.
Глупо?
Размещение информационной системы в облаке начинается с разработки схемы резервного копирования в контролируемую вами инфраструктуру.
Бэкапы-то?
Эта ваша инфраструктура тоже может сдохнуть, сгореть и пр. хоть вы её и контролируете.
В разные. не обязательно вами контролируемые (есть же шифрование). Но обязательно в разные (и принадлежащие разным владельцам).
Может сдохнуть, может сгореть. Но вероятность того, что она сдохнет одновременно с облаком — крайне низка. Другой момент в том, что в какой-то момент в облако вы больше не сможете попасть. Или само облако рассыпалось, или пришел Петя и все пошифровал.
Вы безусловно можете делать бэкап из облака в другое облако. Но вот только стоимость бэкапа в собственную инфраструктуру (пусть это даже стойка в коммерческом ЦОД) весьма невелика. Если же это оказывается для вас слишком дорого — то вы или не умеете считать стоимость данных (полной потери), или ваши данные действительно ничего не стоят.
Вы безусловно можете делать бэкап из облака в другое облако. Но вот только стоимость бэкапа в собственную инфраструктуру (пусть это даже стойка в коммерческом ЦОД) весьма невелика. Если же это оказывается для вас слишком дорого — то вы или не умеете считать стоимость данных (полной потери), или ваши данные действительно ничего не стоят.
Есть другое мнение, и я с ним согласен — www.lastweekinaws.com/blog/multi-cloud-is-the-worst-practice
Краткое содержание.
У нас сделано вот так — а значит это правильно. Правда мы еще ни разу не теряли данные, но ведь облако — это магия, значит и не потеряем.
+ есть мнение, что у автора статьи нет опасности попасть под веерные санкции. Что, вы из России? Давайте до свидания. А нам все равно, что у вас нет бэкапов, что вас не предупреждали и вам некуда пойти, потому что вы не готовы.
У нас сделано вот так — а значит это правильно. Правда мы еще ни разу не теряли данные, но ведь облако — это магия, значит и не потеряем.
+ есть мнение, что у автора статьи нет опасности попасть под веерные санкции. Что, вы из России? Давайте до свидания. А нам все равно, что у вас нет бэкапов, что вас не предупреждали и вам некуда пойти, потому что вы не готовы.
Пользуясь случаем спрошу: а как организуется разворачивание системы на bare-metal, т.е. на серверы вообще без какой-либо ОС? Интересует именно первый шаг, когда есть железо, но нет операционки. Ставить руками — накладно, ведь помимо, собственно, установки нужно ещё поставить какой-то изначальный софт, прописать SSH-ключи, настроить firewall и т.д.
IPMI с единой системой разворачивания образов по сети. По крайней мере так было в Яндексе в 2012 году
Сильно зависит от класса оборудования и количества этих самых развертываний.
Есть theforeman.org и другие.
Тот же pxe с кикстартом позволяет автоматизировать данный процесс
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как спокойно спать, когда у вас облачный сервис: основные архитектурные советы