В целом интересно было почитать, спасибо за статью.
Но некоторые моменты меня смутили, вроде восьмичасового простоя при обновлении при полной недоступности мониторинга.
Восемь часов простоя при обновлении выглядит как фатальный неустранимый недостаток и повод отказаться от подобной системы и уехать на что-нибудь другое.
Почему это вообще не стало причиной отказа от использования Zabbix?
Есть же, к примеру, Sensu как мониторинг, есть специальные стораджи для метрик вроде InfluxDB и Graphite (даже он прекрасно выдержит 20krps на современном железе с SSD), которые, кроме на порядок большей нагрузки, умеют еще и в различные выборки, запросы и агрегирование гибкое (в Graphite можно еще и свои функции написать, благо python).
Для inventory тоже множество решений различных, даже в рамках configuration management утилит. Не знаю есть ли что-то подобное для Ansible, но для Puppet есть специальный модуль который все собирает.
В штатах покушать не довелось, но в ЕС продукты точно качественнее чем в России (в сравнении с Москвой и Петербургом). Очень четко заметил после переезда, подтверждено и моими друзьями, приезжавшими в гости неоднократно. Причем практически все — мясо, рыба, молочка, шоколад, выпечка и т.д.
Отличий не нашел только в рисе и соевых соусах, т.к. всегда в России брал те сорта и виды, которые просто там не производятся.
Я абсолютно с этим согласен — иногда хочется купить именно пакет нормального свежего молока, не заморачиваясь его сроком годности или тем что оно свернется в твоей кружке с кофе — а тут как я понял — только один вид каждого продукта — и это здорово — мне не надо вдаваться чем один кетчуп лучше другого.
Не знаю как в штатах с качеством продуктов (мнения расходятся), но в ЕС в принципе с базовыми продуктами такой проблемы не замечал. Берешь любой бренд, кроме самого дешевого (хотя и там обычно все прилично) и продукт точно будет качественным.
А что касается срока годности — ну так и этот монобрендовый магазин совершенно не застрахован от продажи подобных продуктов. Контролировать срок реализации 1000 бутылок молока одного бренда не сильно проще, если вообще хоть как-то ощутимо проще, чем 10х100 бутылок разных брендов.
Ну и оно конечно фломастеры, но у всех же вкусы разные, поэтому сложно создать кетчуп, подходящий для всех. Это будет какой-то кетчуп, который нравится определенной категории людей. Среднего то, который подойдет всем, как известно, не бывает.
В общем пока это все похоже на локальный тренд для «очень занятых и небедных людей, которые тем не менее не хотят выбирать под свой вкус и готовы довольствоваться каким-то».
Спорно, конечно, но рынок определенно есть, пока есть мода на подобное поведение. И инвесторы явно в это верят. Но в скалирование этого бизнеса в масштабы хоть как-то сопоставимые с амазоном что-то верится с трудом. Хотя, чем черт не шутит, может и правда наберется достаточно людей с таким подходом, они же думали, когда деньги давали.
Вы зачем в политику то ударились?
Я вам все это пишу с общей точки зрения, а не с точки зрения рисков определенной страны.
Это конечно преимущественно русскоязычный ресурс, но это не значит что все тут живут и работают на ex-СССР пространстве.
Нет, не гарантирую конечно, но известных случаев не было.
Если и были, то все получили прекрасную компенсацию и замяли это дело, потому что потеря доверия для такого бизнеса подобна смерти.
Плюс к этому, архитектурно из облака, даже имея доступ во внутренние сети, сложно что-то воровать. Ключи шифрования и данные лежат на разных слоях и доступны разным людям, куча слоев абстракции и т.п.
Да, наверно сотрудник может при острой необходимости и с разрешения службы безопасности попасть на машину, но контролируется это хорошо и уверен что лучше, чем в обычном собственном ДЦ, в котором к слову и так правила весьма и весьма строгие.
А разве с крупными облаками был хоть один подобный случай?
В обычном ДЦ, если он не полностью свой, риски еще выше. Там как минимум сразу понятно из какой стойки оборудование ваше вынимать.
Что то у вас с архитектурой не так, раз такие проблемы возникают.
Для межрегионального трафика существует VPC Peering, который как раз объединяет разные VPC в разных регионах в единое сетевое пространство. Трафик пойдет по каналам амазона.
об этом и речь, поэтому я и не понял, почему вы ставите это плюсом облачных провайдеров.
Как то внезапно я записался в адвокаты облачных решений, но ладно:)
Плюс в том, что там предусмотрены удобюные инструменты, которые позволят минимизировать риски, а во многих случаях вообще без дополнительных телодвижений пережить падение ДЦ. Если самому делать подобные штуки — будет очень дорого и на порядок менее удобно.
Провайдер может побеседовать с клиентом и дать репорт, но реальные изменения в workflow будут делаться в рамках интересов бизнеса amazon
Вот только обеспечение того же уровня у себя будет с высокой вероятностью дороже, или вы считаете что свои специалисты могут сделать лучше и одновременно дешевле, чем специалисты условного Amazon и Google?
Рассуждения в целом верные, но есть момент — является ли IT профильным бизнесом для компании или хотя бы частью ее профиля.
При бюджете 2кк в месяц на IT это или крупная компания, которая производит IT услугу и так или иначе имеет штат специалистов или, к примеру, крупная торговая сеть, для которой это непрофильная деятельности и вот ей дешевле будет купить все это как услугу с минимальным штатом на своей стороне.
При этом, в первом случае облака тоже могут быть дешевле, но тут важны конкретные примеры.
В нашем облаке это правда. Даже самый маленький инстанс может иметь интерфейс в 10Гбит/с без ограничения трафика внутри сети и дополнительных плат.
А зачем это маленькому инстансу, он же умрет просто на обработке сети.
Что будет, если туда подселить 10 подобных инстансов (по остальным ресурсам они, допустим, поместятся)?
Это же явный оверкоммит, еще и в таких объемах. Попасть на соседа, который кушает почти весь канал своей небольшой машинкой — так себе удовольствие.
Да и я что-то не нашел у вас на сайте про это. Есть «частное облако», которое выглядит как блейд с райзером, но стоимость у него ухх. Да и там тоже что-то ничего про 10 Гбит наружу нет, там в целом то всего 2х10 Гбит, как я вижу в конфигурации.
Полностью согласен. Большой объём сканов действительно удобно хранить в S3. И с S3 приятней работать чем с кучей каталогов.
А с чем вы согласны то? Я же сказал ровно обратное — гигабайты сканов в S3, которые часто надо печатать на локальном принтере — не самый лучше выбор, если только S3 бэкап и не более (как и любое другое облачное хранилище).
до первого факапа со стороны провайдера. Aws например вообще не гарантирует сохранность ec2/ebs например.
Забывать конечно нельзя, но вероятность смерти данных в своем ДЦ все таки выше, чем в облаке крупного вендора. Просто по причине заложенной надежности решений и их стоимости.
но зато вспомнить о проблемах коммутации между зонами
Ровно те же проблемы (и даже больше) будет и при своем оборудовании, если начать делать подобные отказоустойчивые решения.
Даже у топовых, таких как амазон случаются форсмажоры, самый яркий — удар молнии в их дц
Конечно бывает, а ДЦ, в который стоит свое оборудование в собственности заговоренные что-ли?:)
Последние годы перевожу компании из облаков на свои сервера.
Какого рода компании? Каковы требования по устойчивости? Можно все поставить в одну стойку и жить спокойно, или надо придумывать disaster recovery планы и есть критичные сервисы? Какой SLA вообще? Что со стоимостью лицензий, с первоначальными вложениями?
Очень много вопросов у меня вызвал это пункт, расскажите если не трудно.
И если бы облака реально были бы дешевле своих серверов, то производители серверов, систем хранения данных, сетевого оборудования для ЦОД стали бы банкротами.
Для облачных компаний сервера делают по контракту те же компании производители железа. Плюс есть другие крупные потребители, которые не могут уходить от своего железа по административным причинам.
Я говорил посчитайте и получалось ещё дороже.
А точно все считали? Какие масштабы?
Пока я могу представить только одну ситуацию, когда свое и правда будет выгоднее безальтернативно — это какая то среднемелкая компания, которой в целом все равно на простой, а надо подешевле и «ну вы сделайте сейчас, оно же точно не упадет, а там решим».
Добавлю еще что с RAID6 стоимость упадет, поэтому что можно обойтись без внешней полки и получить 90 Тб на одной, а значит получается 3000/120 = 25 месяцев. +- конечно, т.к. объем разный, но для оценки пойдет.
Немного ошибся веткой, отвечал khanid
Во многом вы правы, но расчеты на счет стораджа меня несколько смутили.
Запросили цены на объёмы 50-100 Тб данных. И выходит 70-120 т.р. в месяц. При таких ценах уже через полтора года затраты превысят затраты на полноценную СХД. Уже невыгодно при закладывамом минимальном сроке эксплуатации в 3 года (в реальности же — 5-6 лет со сменой дисков).
СХД в практически минимальной комплектации с 12х8000 Гб чистого объема (а мы хотим отказоустойчивость, поэтому смело делем на 2) стоит 1.5 рублей единоразово по минимуму. Теперь берем к нему еще полку на столько же — 600 т.р, чтобы добить объем. Это все в примерных ценах условного DEPO, полки какого-нибудь HP будут еще дороже.
Чтобы обеспечить сопоставимую в облаком отказоустойчивость, нам поидее надо два таких и канал между ними. Просто по железу это будет уже 4.2 миллиона + канал, который мы не знаем сколько стоит, но явно не бесплатный. Ну и конечно за железо в такой конфигурации тоже придется доплатить.
Итого, имеет 4.2 миллиона (а на самом деле больше) за железо с порога + специалисты, которым тоже надо платить, которые болеют, увольняются и обижаются + еще определенное количество расходов, которые мы тут не учли.
Вам же предложили 70-120 т.р в месяц, считаем.
4200/120 (берем максимальную стоимость) = 35 месяцев без учета накладных расходов по обоим решениям.
Но что-то мне кажется из моего опыта, что отказоустойчивый канал до провайдера будет дешевле, чем отказоустойчивая схема обеспечения сотрудниками, которые знают что делать с этой полкой. Вариант совмещения конечно хорошо (админ же не только для полки), но искать его будет уже чуточку сложнее.
В общем, стоимость получается +- такая же если брать сразу весь объем, но сторадж как сервис однозначно дешевле если брать поэтапно или надо будет расширяться больше чем на эти 100 ТБ, так как придется опять капитальные затраты будут большими, а использоваться они будут неэффективно.
В облаке стандартный интерфейс у виртуальной машины 10Гбит/с.
Это, мягко говоря, не совсем правда. Зависит от того, что за облако и что за тип инстанса. Далеко не всегда нужен m5.12xlarge (с которого начинается 10 Гбит/с) с ценой в районе $2.304 в час без прекоммита (итого ~ 1700 долларов в месяц только за вычислительную мощность).
К тому же, никто не отменял требования к обратному каналу с терминального сервера до принтера в офисе, там тоже магии не происходит и на принтер приедет вероятно больше 1 ГБ данных при респечатке 1 Гб сканов, т.к. принтер все таки другими протоколами пользуется.
В таких случая разумно оставлять файлопомойку в офисе и делать к ней синхронизацию во облачный сторадж (S3 + Glacier, допустим), чтобы обеспечить сохранность.
На счет поставить minikube, в Docker for Mac он уже есть — docs.docker.com/docker-for-mac/kubernetes, достаточно ткнуть галочку.
Ну и да, никаких проблем в этом нет.
В целом — ничего особенного.
1. EBS/Compute Engine PD в зависимости от облака. На своем — либо то, что предоставляет OpenStack, допустим, либо iSCSI/CephFS. Хотя последний я недолюбливаю, если честно:)
В целом по эксплуатационной части результат примерно один. Есть еще варианты с локальными стораджами.
2. Базы не очень большие, в пределах десятков ГБ. Postgres, Mongo, Elastic.
3. Проблемы есть ровно те же, как и просто с базами на виртуальных машинах. Исключение — сетевой сторадж, он дает задержки, хотя он и на виртуалках бывает. Но тут решается вариантом мультимастер + локальные стораджи с пересозданием при перезапуске. При условии достаточно стабильной инфраструктуры может быть не очень накладным выходом из ситуации.
4. Принципиальных отличий в стабильности от просто баз, развернутых на виртуалках, не находил.
В целом, Kubernetes позволяет повторить практичечески ту же самую конфигурацию БД, что была бы без него, так что каких-то ограничений (как и больших преимуществ) в переносе баз в него я привести не могу.
Но некоторые моменты меня смутили, вроде восьмичасового простоя при обновлении при полной недоступности мониторинга.
Восемь часов простоя при обновлении выглядит как фатальный неустранимый недостаток и повод отказаться от подобной системы и уехать на что-нибудь другое.
Почему это вообще не стало причиной отказа от использования Zabbix?
Есть же, к примеру, Sensu как мониторинг, есть специальные стораджи для метрик вроде InfluxDB и Graphite (даже он прекрасно выдержит 20krps на современном железе с SSD), которые, кроме на порядок большей нагрузки, умеют еще и в различные выборки, запросы и агрегирование гибкое (в Graphite можно еще и свои функции написать, благо python).
Для inventory тоже множество решений различных, даже в рамках configuration management утилит. Не знаю есть ли что-то подобное для Ansible, но для Puppet есть специальный модуль который все собирает.
Отличий не нашел только в рисе и соевых соусах, т.к. всегда в России брал те сорта и виды, которые просто там не производятся.
Не знаю как в штатах с качеством продуктов (мнения расходятся), но в ЕС в принципе с базовыми продуктами такой проблемы не замечал. Берешь любой бренд, кроме самого дешевого (хотя и там обычно все прилично) и продукт точно будет качественным.
А что касается срока годности — ну так и этот монобрендовый магазин совершенно не застрахован от продажи подобных продуктов. Контролировать срок реализации 1000 бутылок молока одного бренда не сильно проще, если вообще хоть как-то ощутимо проще, чем 10х100 бутылок разных брендов.
Ну и оно конечно фломастеры, но у всех же вкусы разные, поэтому сложно создать кетчуп, подходящий для всех. Это будет какой-то кетчуп, который нравится определенной категории людей. Среднего то, который подойдет всем, как известно, не бывает.
В общем пока это все похоже на локальный тренд для «очень занятых и небедных людей, которые тем не менее не хотят выбирать под свой вкус и готовы довольствоваться каким-то».
Спорно, конечно, но рынок определенно есть, пока есть мода на подобное поведение. И инвесторы явно в это верят. Но в скалирование этого бизнеса в масштабы хоть как-то сопоставимые с амазоном что-то верится с трудом. Хотя, чем черт не шутит, может и правда наберется достаточно людей с таким подходом, они же думали, когда деньги давали.
Вы зачем в политику то ударились?
Я вам все это пишу с общей точки зрения, а не с точки зрения рисков определенной страны.
Это конечно преимущественно русскоязычный ресурс, но это не значит что все тут живут и работают на ex-СССР пространстве.
Если и были, то все получили прекрасную компенсацию и замяли это дело, потому что потеря доверия для такого бизнеса подобна смерти.
Плюс к этому, архитектурно из облака, даже имея доступ во внутренние сети, сложно что-то воровать. Ключи шифрования и данные лежат на разных слоях и доступны разным людям, куча слоев абстракции и т.п.
Да, наверно сотрудник может при острой необходимости и с разрешения службы безопасности попасть на машину, но контролируется это хорошо и уверен что лучше, чем в обычном собственном ДЦ, в котором к слову и так правила весьма и весьма строгие.
В обычном ДЦ, если он не полностью свой, риски еще выше. Там как минимум сразу понятно из какой стойки оборудование ваше вынимать.
Для межрегионального трафика существует VPC Peering, который как раз объединяет разные VPC в разных регионах в единое сетевое пространство. Трафик пойдет по каналам амазона.
Как то внезапно я записался в адвокаты облачных решений, но ладно:)
Плюс в том, что там предусмотрены удобюные инструменты, которые позволят минимизировать риски, а во многих случаях вообще без дополнительных телодвижений пережить падение ДЦ. Если самому делать подобные штуки — будет очень дорого и на порядок менее удобно.
Вот только обеспечение того же уровня у себя будет с высокой вероятностью дороже, или вы считаете что свои специалисты могут сделать лучше и одновременно дешевле, чем специалисты условного Amazon и Google?
При бюджете 2кк в месяц на IT это или крупная компания, которая производит IT услугу и так или иначе имеет штат специалистов или, к примеру, крупная торговая сеть, для которой это непрофильная деятельности и вот ей дешевле будет купить все это как услугу с минимальным штатом на своей стороне.
При этом, в первом случае облака тоже могут быть дешевле, но тут важны конкретные примеры.
А зачем это маленькому инстансу, он же умрет просто на обработке сети.
Что будет, если туда подселить 10 подобных инстансов (по остальным ресурсам они, допустим, поместятся)?
Это же явный оверкоммит, еще и в таких объемах. Попасть на соседа, который кушает почти весь канал своей небольшой машинкой — так себе удовольствие.
Да и я что-то не нашел у вас на сайте про это. Есть «частное облако», которое выглядит как блейд с райзером, но стоимость у него ухх. Да и там тоже что-то ничего про 10 Гбит наружу нет, там в целом то всего 2х10 Гбит, как я вижу в конфигурации.
А с чем вы согласны то? Я же сказал ровно обратное — гигабайты сканов в S3, которые часто надо печатать на локальном принтере — не самый лучше выбор, если только S3 бэкап и не более (как и любое другое облачное хранилище).
Забывать конечно нельзя, но вероятность смерти данных в своем ДЦ все таки выше, чем в облаке крупного вендора. Просто по причине заложенной надежности решений и их стоимости.
Ровно те же проблемы (и даже больше) будет и при своем оборудовании, если начать делать подобные отказоустойчивые решения.
Конечно бывает, а ДЦ, в который стоит свое оборудование в собственности заговоренные что-ли?:)
Какого рода компании? Каковы требования по устойчивости? Можно все поставить в одну стойку и жить спокойно, или надо придумывать disaster recovery планы и есть критичные сервисы? Какой SLA вообще? Что со стоимостью лицензий, с первоначальными вложениями?
Очень много вопросов у меня вызвал это пункт, расскажите если не трудно.
Для облачных компаний сервера делают по контракту те же компании производители железа. Плюс есть другие крупные потребители, которые не могут уходить от своего железа по административным причинам.
А точно все считали? Какие масштабы?
Пока я могу представить только одну ситуацию, когда свое и правда будет выгоднее безальтернативно — это какая то среднемелкая компания, которой в целом все равно на простой, а надо подешевле и «ну вы сделайте сейчас, оно же точно не упадет, а там решим».
Во многом вы правы, но расчеты на счет стораджа меня несколько смутили.
СХД в практически минимальной комплектации с 12х8000 Гб чистого объема (а мы хотим отказоустойчивость, поэтому смело делем на 2) стоит 1.5 рублей единоразово по минимуму. Теперь берем к нему еще полку на столько же — 600 т.р, чтобы добить объем. Это все в примерных ценах условного DEPO, полки какого-нибудь HP будут еще дороже.
Чтобы обеспечить сопоставимую в облаком отказоустойчивость, нам поидее надо два таких и канал между ними. Просто по железу это будет уже 4.2 миллиона + канал, который мы не знаем сколько стоит, но явно не бесплатный. Ну и конечно за железо в такой конфигурации тоже придется доплатить.
Итого, имеет 4.2 миллиона (а на самом деле больше) за железо с порога + специалисты, которым тоже надо платить, которые болеют, увольняются и обижаются + еще определенное количество расходов, которые мы тут не учли.
Вам же предложили 70-120 т.р в месяц, считаем.
4200/120 (берем максимальную стоимость) = 35 месяцев без учета накладных расходов по обоим решениям.
Но что-то мне кажется из моего опыта, что отказоустойчивый канал до провайдера будет дешевле, чем отказоустойчивая схема обеспечения сотрудниками, которые знают что делать с этой полкой. Вариант совмещения конечно хорошо (админ же не только для полки), но искать его будет уже чуточку сложнее.
В общем, стоимость получается +- такая же если брать сразу весь объем, но сторадж как сервис однозначно дешевле если брать поэтапно или надо будет расширяться больше чем на эти 100 ТБ, так как придется опять капитальные затраты будут большими, а использоваться они будут неэффективно.
Это, мягко говоря, не совсем правда. Зависит от того, что за облако и что за тип инстанса. Далеко не всегда нужен m5.12xlarge (с которого начинается 10 Гбит/с) с ценой в районе $2.304 в час без прекоммита (итого ~ 1700 долларов в месяц только за вычислительную мощность).
К тому же, никто не отменял требования к обратному каналу с терминального сервера до принтера в офисе, там тоже магии не происходит и на принтер приедет вероятно больше 1 ГБ данных при респечатке 1 Гб сканов, т.к. принтер все таки другими протоколами пользуется.
В таких случая разумно оставлять файлопомойку в офисе и делать к ней синхронизацию во облачный сторадж (S3 + Glacier, допустим), чтобы обеспечить сохранность.
Теперь есть поддержка SSD и больших томов.
Ну и да, никаких проблем в этом нет.
1. EBS/Compute Engine PD в зависимости от облака. На своем — либо то, что предоставляет OpenStack, допустим, либо iSCSI/CephFS. Хотя последний я недолюбливаю, если честно:)
В целом по эксплуатационной части результат примерно один. Есть еще варианты с локальными стораджами.
2. Базы не очень большие, в пределах десятков ГБ. Postgres, Mongo, Elastic.
3. Проблемы есть ровно те же, как и просто с базами на виртуальных машинах. Исключение — сетевой сторадж, он дает задержки, хотя он и на виртуалках бывает. Но тут решается вариантом мультимастер + локальные стораджи с пересозданием при перезапуске. При условии достаточно стабильной инфраструктуры может быть не очень накладным выходом из ситуации.
4. Принципиальных отличий в стабильности от просто баз, развернутых на виртуалках, не находил.
В целом, Kubernetes позволяет повторить практичечески ту же самую конфигурацию БД, что была бы без него, так что каких-то ограничений (как и больших преимуществ) в переносе баз в него я привести не могу.