Comments 101
> так, дорогой друг, было приятно с тобой работать, но денег на апгрейд железа не дадим
А потом, пару лет спустя, выясняется, что на облако в год тратится столько денег, сколько стоил весь собственный серверный парк…
И админ оказывается крайним со словами «что же ты нам не рассказал, что это НАСТОЛЬКО дорого».
А потом, пару лет спустя, выясняется, что на облако в год тратится столько денег, сколько стоил весь собственный серверный парк…
И админ оказывается крайним со словами «что же ты нам не рассказал, что это НАСТОЛЬКО дорого».
К счатью появляется другой финансовый гений, который предлагает зааутсорсить вообще всё ИТ т.к. инфраструктура уже в облаке, а кадры — это те же капексы.
После полного краха и смены руководства приходит понимание ценности старого доброго лампового инсорса, и всё начинается по-новой )
После полного краха и смены руководства приходит понимание ценности старого доброго лампового инсорса, и всё начинается по-новой )
… но про это нам в статье не расскажут, разумется :)
UFO just landed and posted this here
Ну если делать без ума и под сайт с посещаемостью 100 уников в день выбирать какой нибудь m5.4xlarge (типа с запасом на будущее) — то да, можно влететь в копеечку. Но с таким же успехом админ может закупать ынтерпрайз железо и в офис, бить в себя в грудь, при этом доказывая, что им просто необходима вот эта вот циска за 100500$, потому что стильно/модно/молодежно. Очень многое зависит от руководства, имхо
Вот концептуально облака — это очень правильно!
Но за те деньги, которые нужно будет платить в месяцы без нагрузки, можно арендовать физическое железо и в случае резкого роста нагрузки… просто не заметить, что она выросла :-D
При этом, ещё всякие v-CPU и прочие радости, когда по сути, провайдеры не гарантируют никакой производительности.
Но если всё-таки говорить о концептуальной основе, то я бы аппелировал к другой книжке Таненбаума, а именно "Распределенные системы". Ведь действительно, облака (распределенные системы) позволяют виртуально получить компьютер, который физически сделать очень дорого.
Ну и кстати, отсюда, микросервисы — очень не эффективный способ построения систем, если смотреть со стороны железа, а не говнокодеров, которые все испортят, если там будет больше определенного количества строчек кода...
Хорошо, красиво расписано, но дремать в каморке под шум собственных серверов как то по приятнее, ламповее что ли. :)
Дремать в офисе в нескольких десятках километрах от собственного цода тоже ничего, в общем-то.
UFO just landed and posted this here
Пока там не случилось что-то, связи нет, данных нет, на телефоны не отвечают. Даже представить время простоя не получается.
UFO just landed and posted this here
И позвав людей через некоторое время выбудете знать срок простоя и что можно сделать по быстрому. Все равно точек отказа меньше.
И это не фатализм. Это жизнь. Экскаваторщик вон пару лет назад оптику перерубил магистральную. И все. Сколько ждать никто не знает. Позже кто-то додумался в люк накидать листья осенью и поджечь, опять кабеля накрыло. Капитально при чем....
Объясните мне одну вещь: что будет с сетью при использовании облака? Вот есть файлопомойка со сканами. В случае сервера в офисе у меня гигабит и распечатать гигабайт сканов не проблема. А как быть с файлопомойкой в облаке? А если еще и почту и все остальное положить в облако, то даже 100 мбит инета становится очень мало.
Вы ещё спросите про потери бизнеса при любых проблемах с каналом.
Тут красиво умолчали о том что в случае покупки нового железа старое находит вторую, а то и третью жизнь. А в облаке мы платим только за здесь и сейчас, и вдруг случись что то — все, приехали.
На прошлой работе была не очень хорошая линия к АТС, все грозились поменять на оптоволокно, но для организации выходило дорого. И как то после сильных дождей с ветром залило кабельную шахту, да так что связи не было больше 3 рабочих дней. Почта и бухгалтерия через 3G модем сидела.
На прошлой работе была не очень хорошая линия к АТС, все грозились поменять на оптоволокно, но для организации выходило дорого. И как то после сильных дождей с ветром залило кабельную шахту, да так что связи не было больше 3 рабочих дней. Почта и бухгалтерия через 3G модем сидела.
UFO just landed and posted this here
В первую очередь нужно понять, как бегает ваш трафик до файловой помойки. Если из офиса со стационарных рабочих мест, то видимо не стоит переносить. А если в офисе тонкие клиенты на рабочих местах и вы работаете через терминальный сервер, который тоже в облаке, то как раз стоит. И почту тоже. В облаке стандартный интерфейс у виртуальной машины 10Гбит/с. Плюсы, которые дает работа через терминальный сервер, я расписывать не буду.
В облаке стандартный интерфейс у виртуальной машины 10Гбит/с.
Это, мягко говоря, не совсем правда. Зависит от того, что за облако и что за тип инстанса. Далеко не всегда нужен m5.12xlarge (с которого начинается 10 Гбит/с) с ценой в районе $2.304 в час без прекоммита (итого ~ 1700 долларов в месяц только за вычислительную мощность).
К тому же, никто не отменял требования к обратному каналу с терминального сервера до принтера в офисе, там тоже магии не происходит и на принтер приедет вероятно больше 1 ГБ данных при респечатке 1 Гб сканов, т.к. принтер все таки другими протоколами пользуется.
В таких случая разумно оставлять файлопомойку в офисе и делать к ней синхронизацию во облачный сторадж (S3 + Glacier, допустим), чтобы обеспечить сохранность.
Это, мягко говоря, не совсем правда. Зависит от того, что за облако и что за тип инстанса. Далеко не всегда нужен m5.12xlarge (с которого начинается 10 Гбит/с) с ценой в районе $2.304 в час без прекоммита (итого ~ 1700 долларов в месяц только за вычислительную мощность).
В нашем облаке это правда. Даже самый маленький инстанс может иметь интерфейс в 10Гбит/с без ограничения трафика внутри сети и дополнительных плат.
К тому же, никто не отменял требования к обратному каналу с терминального сервера до принтера в офисе, там тоже магии не происходит и на принтер приедет вероятно больше 1 ГБ данных при респечатке 1 Гб сканов, т.к. принтер все таки другими протоколами пользуется.
В таких случая разумно оставлять файлопомойку в офисе и делать к ней синхронизацию во облачный сторадж (S3 + Glacier, допустим), чтобы обеспечить сохранность.
Полностью согласен. Большой объём сканов действительно удобно хранить в S3. И с S3 приятней работать чем с кучей каталогов.
В нашем облаке это правда. Даже самый маленький инстанс может иметь интерфейс в 10Гбит/с без ограничения трафика внутри сети и дополнительных плат.
А зачем это маленькому инстансу, он же умрет просто на обработке сети.
Что будет, если туда подселить 10 подобных инстансов (по остальным ресурсам они, допустим, поместятся)?
Это же явный оверкоммит, еще и в таких объемах. Попасть на соседа, который кушает почти весь канал своей небольшой машинкой — так себе удовольствие.
Да и я что-то не нашел у вас на сайте про это. Есть «частное облако», которое выглядит как блейд с райзером, но стоимость у него ухх. Да и там тоже что-то ничего про 10 Гбит наружу нет, там в целом то всего 2х10 Гбит, как я вижу в конфигурации.
Полностью согласен. Большой объём сканов действительно удобно хранить в S3. И с S3 приятней работать чем с кучей каталогов.
А с чем вы согласны то? Я же сказал ровно обратное — гигабайты сканов в S3, которые часто надо печатать на локальном принтере — не самый лучше выбор, если только S3 бэкап и не более (как и любое другое облачное хранилище).
А зачем это маленькому инстансу, он же умрет просто на обработке сети.
Что будет, если туда подселить 10 подобных инстансов (по остальным ресурсам они, допустим, поместятся)?
Это же явный оверкоммит, еще и в таких объемах.
Трафик больше 1 Гбит/с уже хочет интерфейс 10Гбит/с
Попасть на соседа, который кушает почти весь канал своей небольшой машинкой — так себе удовольствие.
Это забота облачного оператора, чтоб клиенты не почувствовали.
Да и я что-то не нашел у вас на сайте про это. Есть «частное облако», которое выглядит как блейд с райзером, но стоимость у него ухх. Да и там тоже что-то ничего про 10 Гбит наружу нет, там в целом то всего 2х10 Гбит, как я вижу в конфигурации.
Мы используем порты 10 и 25 Гбит/с на наших серверах.
А с чем вы согласны то? Я же сказал ровно обратное — гигабайты сканов в S3, которые часто надо печатать на локальном принтере — не самый лучше выбор, если только S3 бэкап и не более (как и любое другое облачное хранилище).
Согласен я с вашем мнением, по поводу сетевого взаимодействия с принтером. И с тем, что предпочтительней не гонять тяжёлый трафик через внешний канал.
Становится очень грустно. А если перейти еще и на виртуальные рабочие столы/приложения/RDP и тому подобное, да впихнуть это в все в VPN канал на весь офис… скорость порежется до нескольких мегабит, пинг увеличится с увеличением расстояния до ЦОДа… И тут становится не очень комфортно…
Решается как обычно: «консультантов облака» нужно слушать, а решения принимать самостоятельно, а не «делать все как они рассказывают». В облако есть смысл уносить службы, к которым клиенты через интернет ходят (сайт компании, сервер видеонаблюдения, на котором хранятся видео из филиалов и т.д.). Не стоит переносить в облако ресурсы, если в данный момент основная масса клиентов этого ресурса сидит рядом с сервером, особенно если есть проблема с шириной канала.
Но при этом облако все равно можно использовать для оптимизации вышеуказанных служб.
Например в ваших примерах: основная файлопомойка в офисе, но синхронизируется с облаком в обе стороны. Пока все хорошо, офисные работники работают через быструю локалку с офиснойной копией. Удаленные сотрудники через VPN'ы работают с облачной копией (потому что в облаке интернет шире, чем в офисе). Если в офисе с сервером вдруг что-то случится, то офисные работники перенаправляются в облако, пока все не починят. Да, на время аварии деградирует производительность(из за узкого канала), но уж лучше так, чем «ничего не работает».
С почтой примерно так же поступаем: входящая почта валиться на сервер в облаке, там фильтруется спам, проверяется антивирусом, применяются нужные политики и т.п., а на офисный маилсервер синхронизируются только нужные письма.
Инфраструктура конечно получается сложнее, чем простое «один сервер выполняет одну роль и по ночам бэкапится», в зависимости от конкретного стека и требований возможно что придется пойти на некоторые компромиссы, но обычно оно того стоит если сервисы действительно критичные для компании.
Но при этом облако все равно можно использовать для оптимизации вышеуказанных служб.
Например в ваших примерах: основная файлопомойка в офисе, но синхронизируется с облаком в обе стороны. Пока все хорошо, офисные работники работают через быструю локалку с офиснойной копией. Удаленные сотрудники через VPN'ы работают с облачной копией (потому что в облаке интернет шире, чем в офисе). Если в офисе с сервером вдруг что-то случится, то офисные работники перенаправляются в облако, пока все не починят. Да, на время аварии деградирует производительность(из за узкого канала), но уж лучше так, чем «ничего не работает».
С почтой примерно так же поступаем: входящая почта валиться на сервер в облаке, там фильтруется спам, проверяется антивирусом, применяются нужные политики и т.п., а на офисный маилсервер синхронизируются только нужные письма.
Инфраструктура конечно получается сложнее, чем простое «один сервер выполняет одну роль и по ночам бэкапится», в зависимости от конкретного стека и требований возможно что придется пойти на некоторые компромиссы, но обычно оно того стоит если сервисы действительно критичные для компании.
UFO just landed and posted this here
Дааа, собственный VPN сервер это нынче крайне дорого и затратно. А главное специалистов по настройке днем с огнем не сыщешь. :)
UFO just landed and posted this here
UFO just landed and posted this here
Стоит задача: организовать доступ сотруднику к удаленным документам. Как проще всего решить? Через VPN сервер. Просто, надежно, дешево, что клиентов, что серверов разве что под кофеварку нет. Зачем облако городить? Что бы дяде посреднику, между мной и моими данными, денежку отдавать?
UFO just landed and posted this here
Это управляемые риски. Можно посчитать их вероятность, стоимость их компенсации и решить, нужно их закрывать или нет.
А вот когда ровно те же проблемы появляются у провайдера облака — это не управляемые клиентом риски. Провайдер облака решил построить решение вот так, потому что ему кажется, что так будет правильно. Но при падении — я не знаю провайдеров облачных решений, которые готовы полностью оплачивать ущерб бизнесу из-за отсутствия сервиса. Поэтому и гарантии с облаком — в размере абонплаты.
А вот когда ровно те же проблемы появляются у провайдера облака — это не управляемые клиентом риски. Провайдер облака решил построить решение вот так, потому что ему кажется, что так будет правильно. Но при падении — я не знаю провайдеров облачных решений, которые готовы полностью оплачивать ущерб бизнесу из-за отсутствия сервиса. Поэтому и гарантии с облаком — в размере абонплаты.
Но при падении — я не знаю провайдеров облачных решений, которые готовы полностью оплачивать ущерб бизнесу из-за отсутствия сервиса. Поэтому и гарантии с облаком — в размере абонплаты.
Так это стандартная практика во всем мире во всех отраслях. Производители серверов сломавшийся сервер вам поменяют, но оплачивать убытки из-за его простоя не будут. Автопроизводители починят сломавшийся автомобиль, но если не будут вам оплачивать упущенную прибыль сорвавшейся сделки, даже если она сорвалась из-за поломки автомобиля и так почти везде.
Если хотите застраховаться от подобных проблем, но стоит обращаться в профильные организации, то есть в страховые компании. Причем если верить гуглу, то даже в России есть облачные провайдеры, которые сотрудничают со страховыми компаниями и вполне могут предоставить подобные услуги. Но нужно понимать что страховая сумма будет всегда ограниченна сверху и напрямую привязана к страховым взносам.
Согласен. Я бы даже сказал по другому, что инфраструктура — это ответственность компании, а не провайдера.
Нужно самим думать, что лучше, заплатить за дублирующую функциональность (полную или неполную), или какое-то время не работать и решать по ходу возникновения проблемы.
Ну так вы повторили ровно то, что сказал я.
Облачные решения проигрывают именно по вопросам обеспечения уровня сервиса. То, что это стандартная практика, не делает облачных провайдеров лучше собственной инфраструктуры.
Облачные решения проигрывают именно по вопросам обеспечения уровня сервиса. То, что это стандартная практика, не делает облачных провайдеров лучше собственной инфраструктуры.
Сидящих на Хабре сисадминов предсказуемо бомбит ;)
UFO just landed and posted this here
Значит вы будущий сисадмин ;)
1. Цена — не единственный параметр при выборе перехода в облако.
2. Цена — вопрос сложный, конечно, можно считать цены по листпрайсу, и удивляться, почему дорого. Но это скорее говорит о компетентности считающего, чем о реальной цене облака.
1. Цена — не единственный параметр при выборе перехода в облако.
2. Цена — вопрос сложный, конечно, можно считать цены по листпрайсу, и удивляться, почему дорого. Но это скорее говорит о компетентности считающего, чем о реальной цене облака.
> 1. Цена — не единственный параметр
На самом деле, облако — это дорого.
> 2. Цена — вопрос сложный
На самом деле, облако — это очень дорого.
Всё, что вам нужно знать про облака.
На самом деле, облако — это дорого.
> 2. Цена — вопрос сложный
На самом деле, облако — это очень дорого.
Всё, что вам нужно знать про облака.
UFO just landed and posted this here
> Простите, а как еще принято считать?
По крайней мере владея всеми возможными средствами оптимизации цены.
Тем более, что обычно для этого достаточно хотя бы погуглить.
aws.amazon.com/ru/blogs/rus/cost-optimization-capabilities
habr.com/post/331566
habr.com/company/bitrix/blog/174181
Так называемые «спотовые» и «контрактные» цены, например, позволяют снизить стоимость владения иногда в десятки раз. И это только единственный способ. А их еще с десяток.
Разумеется, если переносить имеющуюся инфраструктуру «один-в-один» то получится как вы и считали, это как минимум глупо. Глупо натягивать сову на глобус, оставьте подход «свой датацентр, как мне привычно» в своем датацентре. На то оно и облако.
Но тем не менее сисадмины занимаются этим снова и снова. Вне зависимости от возраста.
По крайней мере владея всеми возможными средствами оптимизации цены.
Тем более, что обычно для этого достаточно хотя бы погуглить.
aws.amazon.com/ru/blogs/rus/cost-optimization-capabilities
habr.com/post/331566
habr.com/company/bitrix/blog/174181
Так называемые «спотовые» и «контрактные» цены, например, позволяют снизить стоимость владения иногда в десятки раз. И это только единственный способ. А их еще с десяток.
Разумеется, если переносить имеющуюся инфраструктуру «один-в-один» то получится как вы и считали, это как минимум глупо. Глупо натягивать сову на глобус, оставьте подход «свой датацентр, как мне привычно» в своем датацентре. На то оно и облако.
Но тем не менее сисадмины занимаются этим снова и снова. Вне зависимости от возраста.
"Простите, а как еще принято считать? Забухать с владельцем сервиса и договориться о специальной цене, что ли? "
Зачёт!!!
У меня такое впечатление, что там нужно отдельно заканчивать университет облачный факультет, и там должны быть кафедры на выбор Амазон, Гугл и МикроСофт, чтобы иметь хоть приблизительное представление о том, сколько в конечном счёте будут стоить услуги.
> У меня такое впечатление, что там нужно отдельно заканчивать университет облачный факультет
Ну что надо заканчивать «университет необлачный факультет» для того, чтобы правильно спроектировать современный датацентр вас не удивляет, то почему удивляет тут?
Ну что надо заканчивать «университет необлачный факультет» для того, чтобы правильно спроектировать современный датацентр вас не удивляет, то почему удивляет тут?
Я имею ввиду именно определение стоимости.
Если администратор спроектирует дата-центр, то потом стоимость может посчитать школьник в столбик.
А вот узнать конечную цену у основных облачных провайдеров — это нереально. При этом, все в одну сторону, так как они ещё и ничего не обещают в плане производительности.
Моя коллега готовила статью как раз на эту тему, Вот тут можно прочитать подробнее
Слишком много упрощений и допущений.
Ныне это уже эдакий entry-level. Если при найме на работу у будущего админа нет понимания, что есть виртуализация — ему, пожалуй, рано в админы. Напроситься помощником разве что. Опыт тут даже не при чём. Виртуализация сейчас везде и всюду. Там где её нет — это, как правило, специфика или отсутствие необходимости в какой-либо весомой инфраструктуре. И даже в таком случае плюсы виртуализации весомее минусов и оверхеда.
Решается просто сравнением предложения IaaS вендора со строимостью оборудования + стоимостью его владения.
Простой пример из недавнего. Пришло предложение на хранение данных. Вроде дело хорошее. Запросили цены на объёмы 50-100 Тб данных. И выходит 70-120 т.р. в месяц. При таких ценах уже через полтора года затраты превысят затраты на полноценную СХД. Уже невыгодно при закладывамом минимальном сроке эксплуатации в 3 года (в реальности же — 5-6 лет со сменой дисков). Можно включить затраты на содержание СХД, но тогда надо включать и затраты на доступ к облаку. До этого, честно скажу, даже не дошло, поскольку IaaS провайдер не смотря на наличие собственной сетевой инфраструктуры как ISP, вопрос доступа обошёл стороной, но дав понять, что халявного подключения через них не будет. И при таких объёмах не 100 Мбит надо. Всё описанное — это только на хранение. На полноценную IaaS затраты выходят больше. Как на доступность, так и на оплату мощностей. Даже копеечные БД по 20-50 Гб будут загибаться по производительности на дешёвых конфигах.
Обычно это проблем не доставляет, поскольку заранее подбирается совместимое оборудование. Никто в здравом уме не берёт железо наугад в разнобой.
Вот только сроки решения. Конечно, есть всякие SLA, но, как показывает история последних 10 лет, IaaS уходит в отказ и сделать что либо становится затруднительным. Даже у таких гигантов как Amazon бывают факапы. Достаточно вспомнить безвозвратное удаление кучи EC2 (кажется) инстансов, когда у них возникло подозрение на возможность попадания данных не владельцу, например.
Принципиальной разницы же просто нет в сравнении со своей инфраструктурой.
Здесь идёт какое-то непонятное упрощение. Принципиальной разницы же нет, кроме наличия железа в стойке.
Это, скорее, из разряда чего-то еординарного. При той же виртуализации коммутация — эдакая software-defined составляющая, если говорить о подключении серверов к сети.
3PAR — это уже не малый бизнес. Там все плюхи кровавого энтерпрайза. И, что характерно, принципиальной разницы же нет при понимании сути. Достаточная изученность какой-нибудь MSA, вполне себе может быть нормальной платформой для безболезненного перехода на что-то иное или более серьёзное. Что же касается планирования — оно и в облаке никуда не девается. Определённый уровень IOPS никто не отменял. В части своей же инфраструктуры это тоже не вызовет проблем. На более серьёзном оборудовании data-tiering вполне себе существует. А на более простом переезд конфигурации и данных с одного хранилища в друге не представляет сколь либо большой проблемы. В том же win 2012 HA-cluster это тупо несколько кликов по контекстным меню, где просто выбирается другое хранилище/раздел под конфиг/диски ВМ. Ну и дальше идёт безостановочный (а это важно, поскольку вся аргументация на этом) процесс переезда. Побочные эффекты — ну разве что снижение производительности на время переезда. Но это и делается не в пик нагрузки обычно.
Прямая попытка противопоставления облако vs своя инфраструктура — не очень. Очень тяжело сказать, что вот это в таком решении безальтернативно лучше, а вот это — безальтернативно хуже. Оно, скорее, просто другое.
Опытные админы уже попробовали какую-то виртуализацию
Ныне это уже эдакий entry-level. Если при найме на работу у будущего админа нет понимания, что есть виртуализация — ему, пожалуй, рано в админы. Напроситься помощником разве что. Опыт тут даже не при чём. Виртуализация сейчас везде и всюду. Там где её нет — это, как правило, специфика или отсутствие необходимости в какой-либо весомой инфраструктуре. И даже в таком случае плюсы виртуализации весомее минусов и оверхеда.
Потому что это капитальные затраты, которые нашему бизнесу совершенно не нужны.
Решается просто сравнением предложения IaaS вендора со строимостью оборудования + стоимостью его владения.
Простой пример из недавнего. Пришло предложение на хранение данных. Вроде дело хорошее. Запросили цены на объёмы 50-100 Тб данных. И выходит 70-120 т.р. в месяц. При таких ценах уже через полтора года затраты превысят затраты на полноценную СХД. Уже невыгодно при закладывамом минимальном сроке эксплуатации в 3 года (в реальности же — 5-6 лет со сменой дисков). Можно включить затраты на содержание СХД, но тогда надо включать и затраты на доступ к облаку. До этого, честно скажу, даже не дошло, поскольку IaaS провайдер не смотря на наличие собственной сетевой инфраструктуры как ISP, вопрос доступа обошёл стороной, но дав понять, что халявного подключения через них не будет. И при таких объёмах не 100 Мбит надо. Всё описанное — это только на хранение. На полноценную IaaS затраты выходят больше. Как на доступность, так и на оплату мощностей. Даже копеечные БД по 20-50 Гб будут загибаться по производительности на дешёвых конфигах.
Как у него вот это железо от одного производителя будет работать с железом другого производителя
Обычно это проблем не доставляет, поскольку заранее подбирается совместимое оборудование. Никто в здравом уме не берёт железо наугад в разнобой.
Не нужна диагностика аппаратных сбоев: проблемы решаются оператором
Вот только сроки решения. Конечно, есть всякие SLA, но, как показывает история последних 10 лет, IaaS уходит в отказ и сделать что либо становится затруднительным. Даже у таких гигантов как Amazon бывают факапы. Достаточно вспомнить безвозвратное удаление кучи EC2 (кажется) инстансов, когда у них возникло подозрение на возможность попадания данных не владельцу, например.
Все виртуальные машины в облаке могут быть скопированы по расписанию, которое задаёт админ. Главное — не забыть создать это расписание. Можно копировать ВМ целиком, можно определённые элементы типа баз данных.
Принципиальной разницы же просто нет в сравнении со своей инфраструктурой.
Нет проблем с аппаратными файрволлами
Здесь идёт какое-то непонятное упрощение. Принципиальной разницы же нет, кроме наличия железа в стойке.
Переключение серверов в стойке в разные сети руками уже не надо.
Это, скорее, из разряда чего-то еординарного. При той же виртуализации коммутация — эдакая software-defined составляющая, если говорить о подключении серверов к сети.
В среднем и малом бизнесе часто приходит человек, который настроил у себя NetApp, HP 3Par или вообще гордый бренд Noname. Что досталось, то и изучили: это вторичный рынок железок после апгрейдов из больших компаний. А каждая СХД — это свой интерфейс, свои системы управления, свой мониторинг. Админы заранее сильно думают, куда и что размещать: какие данные на SSD, какие на медленные диски. В случае, если он сразу запланировал неверно, потом будет плохо. Миграция данных с одного типа носителей на другой — это настоящая боль. В физике — это всегда остановка связи. А в облаке — перевод данных с одного типа носителя на другой в три клика. В момент копирования сервис предоставляется. Занимает процесс чуть больше, чем время на само копирование.
3PAR — это уже не малый бизнес. Там все плюхи кровавого энтерпрайза. И, что характерно, принципиальной разницы же нет при понимании сути. Достаточная изученность какой-нибудь MSA, вполне себе может быть нормальной платформой для безболезненного перехода на что-то иное или более серьёзное. Что же касается планирования — оно и в облаке никуда не девается. Определённый уровень IOPS никто не отменял. В части своей же инфраструктуры это тоже не вызовет проблем. На более серьёзном оборудовании data-tiering вполне себе существует. А на более простом переезд конфигурации и данных с одного хранилища в друге не представляет сколь либо большой проблемы. В том же win 2012 HA-cluster это тупо несколько кликов по контекстным меню, где просто выбирается другое хранилище/раздел под конфиг/диски ВМ. Ну и дальше идёт безостановочный (а это важно, поскольку вся аргументация на этом) процесс переезда. Побочные эффекты — ну разве что снижение производительности на время переезда. Но это и делается не в пик нагрузки обычно.
Прямая попытка противопоставления облако vs своя инфраструктура — не очень. Очень тяжело сказать, что вот это в таком решении безальтернативно лучше, а вот это — безальтернативно хуже. Оно, скорее, просто другое.
Немного ошибся веткой, отвечал khanid
Во многом вы правы, но расчеты на счет стораджа меня несколько смутили.
СХД в практически минимальной комплектации с 12х8000 Гб чистого объема (а мы хотим отказоустойчивость, поэтому смело делем на 2) стоит 1.5 рублей единоразово по минимуму. Теперь берем к нему еще полку на столько же — 600 т.р, чтобы добить объем. Это все в примерных ценах условного DEPO, полки какого-нибудь HP будут еще дороже.
Чтобы обеспечить сопоставимую в облаком отказоустойчивость, нам поидее надо два таких и канал между ними. Просто по железу это будет уже 4.2 миллиона + канал, который мы не знаем сколько стоит, но явно не бесплатный. Ну и конечно за железо в такой конфигурации тоже придется доплатить.
Итого, имеет 4.2 миллиона (а на самом деле больше) за железо с порога + специалисты, которым тоже надо платить, которые болеют, увольняются и обижаются + еще определенное количество расходов, которые мы тут не учли.
Вам же предложили 70-120 т.р в месяц, считаем.
4200/120 (берем максимальную стоимость) = 35 месяцев без учета накладных расходов по обоим решениям.
Но что-то мне кажется из моего опыта, что отказоустойчивый канал до провайдера будет дешевле, чем отказоустойчивая схема обеспечения сотрудниками, которые знают что делать с этой полкой. Вариант совмещения конечно хорошо (админ же не только для полки), но искать его будет уже чуточку сложнее.
В общем, стоимость получается +- такая же если брать сразу весь объем, но сторадж как сервис однозначно дешевле если брать поэтапно или надо будет расширяться больше чем на эти 100 ТБ, так как придется опять капитальные затраты будут большими, а использоваться они будут неэффективно.
Во многом вы правы, но расчеты на счет стораджа меня несколько смутили.
Запросили цены на объёмы 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 ТБ, так как придется опять капитальные затраты будут большими, а использоваться они будут неэффективно.
Нифига. Внедрение software defined networks вызывает совершенную passive-agressive реакцию сетевого отдела, даже если они сдерживаются. Если же речь идёт про SDN уровня дата-центра (bgp, dynamic egress ballancing), или про оверлейную сеть на сетевом оборудовании (не путать про оверлейные сети на хостах), то реакция становится просто сардонической. Потому что понять что происходит на сетевом оборудовании можно только через инструментарий управляющего ПО — если посмотреть на конфиги оборудования, то там тысячи vlan/vxlan, динамически появляющиеся/исчезающие vrf'ы, и даже нельзя (без заглядывания в управляющее ПО) понять с кем из свичей устанавливается BGP-сессия.
Автоматизация приходит к автоматизаторам, и не все из неё выйдут в статусе гуру.
Автоматизация приходит к автоматизаторам, и не все из неё выйдут в статусе гуру.
Вендоры хотят кушать и хотят кушать всегда. Вдруг компания будет сидеть n лет на 1них серверах, и не захочет i7 менять на новый i7+, старое ПО на новое ПО+, где они затратились на новые свистелки. На облаках вы то денюжки им постоянно несете.
Облака иногда полезны, но надо уметь считать, и считать хорошо, чтобы понять, где вам будет выгоднее переезд на другие железки у дяди, которые делает тоже самое что и вы, но еще свою маржу будет с вас иметь.
Облака иногда полезны, но надо уметь считать, и считать хорошо, чтобы понять, где вам будет выгоднее переезд на другие железки у дяди, которые делает тоже самое что и вы, но еще свою маржу будет с вас иметь.
Последние годы перевожу компании из облаков на свои сервера. Ибо оказывается, что аренда ЦОД, свои сервера и СХД плюс самый быстрый сервис от вендора, софт виртализауии с самой быстрой поддержкой от вендора, ОС, аутсорсинг админов поддержки стоит в 3-5 раз дешевле облаков при расчете на 3/4/5 лет.
Поймите простую истину. Облачные провайдеры типа Amazon, Azure используют кастомные (не серийные) сервера. И если бы облака реально были бы дешевле своих серверов, то производители серверов, систем хранения данных, сетевого оборудования для ЦОД стали бы банкротами. Однако крупнейшие мировые производители отчитываются о росте продаж и росте всего рынка!
Уже не раз при проведении тендера на закупку оборудования, лицензирования, поддержки продавцы меня спрашивали зачем все это, купите у нас облака. Я говорил посчитайте и получалось ещё дороже.
Облака — новый способ получить дополнительную прибыль, создав дополнительную ценность для узкого круга клиентов.
Облака выгодно использовать в определённых случаях:
стандартизированные услуги типа хостинг, почта, телефония, портальные решения и т.п.
катастрофоустойчивость — реплики серверов, баз данных, бэкапов.
не постоянные нагрузки — повышенный спрос, сезон, сдача отчётности, пилотный проект, тестирование, сборка приложений
когда скорость запуска/изменений дороже денег на разницу стоимости облаков/своего ИТ
дорогие специалисты по определенной технологии в стране/регионе
нет специалистов по новым технологиям
ваучер для стартапов
и реально большие, транснациональные даже не компании а корпорации с публичными сервисами для десятков тысяч/миллионов клиентов.
Поймите простую истину. Облачные провайдеры типа Amazon, Azure используют кастомные (не серийные) сервера. И если бы облака реально были бы дешевле своих серверов, то производители серверов, систем хранения данных, сетевого оборудования для ЦОД стали бы банкротами. Однако крупнейшие мировые производители отчитываются о росте продаж и росте всего рынка!
Уже не раз при проведении тендера на закупку оборудования, лицензирования, поддержки продавцы меня спрашивали зачем все это, купите у нас облака. Я говорил посчитайте и получалось ещё дороже.
Облака — новый способ получить дополнительную прибыль, создав дополнительную ценность для узкого круга клиентов.
Облака выгодно использовать в определённых случаях:
стандартизированные услуги типа хостинг, почта, телефония, портальные решения и т.п.
катастрофоустойчивость — реплики серверов, баз данных, бэкапов.
не постоянные нагрузки — повышенный спрос, сезон, сдача отчётности, пилотный проект, тестирование, сборка приложений
когда скорость запуска/изменений дороже денег на разницу стоимости облаков/своего ИТ
дорогие специалисты по определенной технологии в стране/регионе
нет специалистов по новым технологиям
ваучер для стартапов
и реально большие, транснациональные даже не компании а корпорации с публичными сервисами для десятков тысяч/миллионов клиентов.
Последние годы перевожу компании из облаков на свои сервера.
Какого рода компании? Каковы требования по устойчивости? Можно все поставить в одну стойку и жить спокойно, или надо придумывать disaster recovery планы и есть критичные сервисы? Какой SLA вообще? Что со стоимостью лицензий, с первоначальными вложениями?
Очень много вопросов у меня вызвал это пункт, расскажите если не трудно.
И если бы облака реально были бы дешевле своих серверов, то производители серверов, систем хранения данных, сетевого оборудования для ЦОД стали бы банкротами.
Для облачных компаний сервера делают по контракту те же компании производители железа. Плюс есть другие крупные потребители, которые не могут уходить от своего железа по административным причинам.
Я говорил посчитайте и получалось ещё дороже.
А точно все считали? Какие масштабы?
Пока я могу представить только одну ситуацию, когда свое и правда будет выгоднее безальтернативно — это какая то среднемелкая компания, которой в целом все равно на простой, а надо подешевле и «ну вы сделайте сейчас, оно же точно не упадет, а там решим».
Подтверждаю тренд. Чем крупнее компания, тем выгоднее для неё baremetal (арендованный или свой).
Идеальный клиент для облаков, получающий от них фантастическую экономию — пользователь одинокого инстанса минимального размера, который почти ничего не делает, и вообще, появляется на свет иногда.
Вот в этом режиме никто не сможет побить клаудный рейт в 1¢/час (100 часов в месяц — евро!).
А вот как только появляется постоянная нагрузка, то перенос постоянной нагрузки на свои мощности начинает давать экономию пропорционально масштабу.
Т.е. при IT-бюджете в 200 баксов в месяц — облака и только облака.
При бюджете в 200к баксов в месяц — на облака можно выносить только волатильную часть инфрастурктуры (всякие CI, ephimerial staging и т.д.).
При бюджете в 2kk баксов в месяц, можно и их in house держать — дешевле будет.
Идеальный клиент для облаков, получающий от них фантастическую экономию — пользователь одинокого инстанса минимального размера, который почти ничего не делает, и вообще, появляется на свет иногда.
Вот в этом режиме никто не сможет побить клаудный рейт в 1¢/час (100 часов в месяц — евро!).
А вот как только появляется постоянная нагрузка, то перенос постоянной нагрузки на свои мощности начинает давать экономию пропорционально масштабу.
Т.е. при IT-бюджете в 200 баксов в месяц — облака и только облака.
При бюджете в 200к баксов в месяц — на облака можно выносить только волатильную часть инфрастурктуры (всякие CI, ephimerial staging и т.д.).
При бюджете в 2kk баксов в месяц, можно и их in house держать — дешевле будет.
Рассуждения в целом верные, но есть момент — является ли IT профильным бизнесом для компании или хотя бы частью ее профиля.
При бюджете 2кк в месяц на IT это или крупная компания, которая производит IT услугу и так или иначе имеет штат специалистов или, к примеру, крупная торговая сеть, для которой это непрофильная деятельности и вот ей дешевле будет купить все это как услугу с минимальным штатом на своей стороне.
При этом, в первом случае облака тоже могут быть дешевле, но тут важны конкретные примеры.
При бюджете 2кк в месяц на IT это или крупная компания, которая производит IT услугу и так или иначе имеет штат специалистов или, к примеру, крупная торговая сеть, для которой это непрофильная деятельности и вот ей дешевле будет купить все это как услугу с минимальным штатом на своей стороне.
При этом, в первом случае облака тоже могут быть дешевле, но тут важны конкретные примеры.
А 200к?
Кстати, если бюджет IT 2кк, то купить услугу не будет дешевле. На таких суммах затраты на специалистов уже несущественные и они примерно o(log n), а затраты на оборудование — o(n), при этом поставщик клауда закладывает маржу как константу от цены услуги (утрируя, цены оборудования), да ещё и помноженную на время. Т.е. получаем переплату в размере o(n*t), что совсем неприлично. Для маленьких контор тут есть фактор «больше на зарплаты потратим», но для большого бюджета — это во-первых не существенно, а во-вторых волшебное поле трушной оптимизации и автоматизации.
Соответственно, чем меньше контора, тем выгоднее ей облака. Можно сказать и наоборот, по мере роста компании ей надо уходить с облаков на self-hosted. А из этого вырастает ещё интереснейшая штука: архитектуру надо с самого начала закладывать такую, которая может жить как и cloud native, так и на self-hosted. Это означает, что смысл имеет использовать только те сервисы, которые могут быть воссозданы in house (что на практике означает «имеют удобные opensource варианты»).
Кстати, если бюджет IT 2кк, то купить услугу не будет дешевле. На таких суммах затраты на специалистов уже несущественные и они примерно o(log n), а затраты на оборудование — o(n), при этом поставщик клауда закладывает маржу как константу от цены услуги (утрируя, цены оборудования), да ещё и помноженную на время. Т.е. получаем переплату в размере o(n*t), что совсем неприлично. Для маленьких контор тут есть фактор «больше на зарплаты потратим», но для большого бюджета — это во-первых не существенно, а во-вторых волшебное поле трушной оптимизации и автоматизации.
Соответственно, чем меньше контора, тем выгоднее ей облака. Можно сказать и наоборот, по мере роста компании ей надо уходить с облаков на self-hosted. А из этого вырастает ещё интереснейшая штука: архитектуру надо с самого начала закладывать такую, которая может жить как и cloud native, так и на self-hosted. Это означает, что смысл имеет использовать только те сервисы, которые могут быть воссозданы in house (что на практике означает «имеют удобные opensource варианты»).
Последние годы перевожу компании из облаков на свои сервера. Ибо оказывается, что аренда ЦОД, свои сервера и СХД плюс самый быстрый сервис от вендора, софт виртализауии с самой быстрой поддержкой от вендора, ОС, аутсорсинг админов поддержки стоит в 3-5 раз дешевле облаков при расчете на 3/4/5 лет.
Действую подобным образом вы имеете все шансы стать новым облачным провайдером для своих клиентов.
Ещё одна масштабная вещь — это обучение. Если у вас не ноунейм, а что-то вроде HP или Dell, то надо либо покупать поддержку, либо обучаться у вендоров. Либо искать спецов, когда приспичит.а что в облаке этот пункт чудесным образом исчезает? Или вы хотите сказать, что с тем же aws разберется любой сисадмин?
Можно почти забыть про резервное копирование и его особенности в организации.до первого факапа со стороны провайдера. Aws например вообще не гарантирует сохранность ec2/ebs например. И в любой момент ваша виртуалка может уйти на покой. Ну и у каждого провайдера куча тонкостей и граблей с бекапом для каждого сервиса, так что не все так радужно, как вы описываете
Можно забыть о проблемах с коммутацией оборудования.но зато вспомнить о проблемах коммутации между зонами
Нет проблемы с питанием в здании и его резервированием.очень сильно зависит от уровня провайдера. Даже у топовых, таких как амазон случаются форсмажоры, самый яркий — удар молнии в их дц
Очень много придётся учить СХД.не понял, а зачем мне учить схд при использовании того же aws/gcp?
до первого факапа со стороны провайдера. Aws например вообще не гарантирует сохранность ec2/ebs например.
Забывать конечно нельзя, но вероятность смерти данных в своем ДЦ все таки выше, чем в облаке крупного вендора. Просто по причине заложенной надежности решений и их стоимости.
но зато вспомнить о проблемах коммутации между зонами
Ровно те же проблемы (и даже больше) будет и при своем оборудовании, если начать делать подобные отказоустойчивые решения.
Даже у топовых, таких как амазон случаются форсмажоры, самый яркий — удар молнии в их дц
Конечно бывает, а ДЦ, в который стоит свое оборудование в собственности заговоренные что-ли?:)
Факапы со своей стороны часто могут быть предсказаны, а в режиме разбора полётов — устранены в дальнейшем. Факап амазона звучит как письмо и покерфейс (у нас SLA выполняется — свободы), с нулевыми перспективами участвовать в разборе полётов.
с нулевыми перспективами участвовать в разборе полётов.ну только если вы ОЧЕНЬ «жирный» клиент, то может вас и пригласят послушать :) Вроде помню была статья на хабре, когда человека начал аффектить баг ebs, если не ошибаюсь, в результате чего он потерял несколько виртуалок. Так вот там он вроде с личным менеджером амазон общался с ведущим разработчиком. Так что шансы есть :)
Это не разбор полётов. Разбор полётов включает не только выяснение технической причины, но и обсуждение административных изменений. Добавление тестов, мониторинга, назначение обязанностей на персонал, пересмотр административной структуры и т.д. Провайдер может побеседовать с клиентом и дать репорт, но реальные изменения в workflow будут делаться в рамках интересов бизнеса amazon (например, если amazon устраивает текущий рейт отказов, то дальше будет sales dance, даже если он выполняется с участием ведущего разработчика).
Кто сотрудников зарплатит, тот их и строит.
Кто сотрудников зарплатит, тот их и строит.
Провайдер может побеседовать с клиентом и дать репорт, но реальные изменения в workflow будут делаться в рамках интересов бизнеса amazon
Вот только обеспечение того же уровня у себя будет с высокой вероятностью дороже, или вы считаете что свои специалисты могут сделать лучше и одновременно дешевле, чем специалисты условного Amazon и Google?
Конечно бывает, а ДЦ, в который стоит свое оборудование в собственности заговоренные что-ли?:)об этом и речь, поэтому я и не понял, почему вы ставите это плюсом облачных провайдеров.
Последние пару лет я работаю исключительно с aws/gcp и самый большой плюс для меня — это возможность сконцентрироваться на решение конкретной задачи, а не ковыряться и выяснять причины, почему данный рейд контроллер не работает и/или глючит с данным ядром. Или почему СХД начала тормозить и т.п. Своих багов/костылей тоже хватает, но вот возможность практически полностью абстрагироваться от аппаратного уровня — это большой плюс. Ну и конечно плюсом будет приятные плюшки в виде terraform и т.п. вещей.
об этом и речь, поэтому я и не понял, почему вы ставите это плюсом облачных провайдеров.
Как то внезапно я записался в адвокаты облачных решений, но ладно:)
Плюс в том, что там предусмотрены удобюные инструменты, которые позволят минимизировать риски, а во многих случаях вообще без дополнительных телодвижений пережить падение ДЦ. Если самому делать подобные штуки — будет очень дорого и на порядок менее удобно.
Коллега onlinehead меня опередил.
Добавлю про обучение.
Речь шла о железе. А с интерфейсом облака придётся дружить, я об этом писал, здесь я согласен.
Добавлю про обучение.
а что в облаке этот пункт чудесным образом исчезает? Или вы хотите сказать, что с тем же aws разберется любой сисадмин?
Речь шла о железе. А с интерфейсом облака придётся дружить, я об этом писал, здесь я согласен.
deleted
Для РФ выпадает очень вкусный западный пункт — переход на новые процессоры и платформы раз в N лет (3-5) для экономии электроэнергии. Там на тех же вычислительных мощностях это может заметно сказываться. У нас по меркам европы электричество дешёвое.
Единственное, что меня напрягает во всех этих переездах в облако в стороннем ДЦ — это безопасность. Кто сможет гарантировать, что ваши данные не утекут из самого ДЦ или где-то по дороге от вас к ним?
Никто. Максимум — договор, в которой оговорены все нюансы. Но это уже к юристам.
Облака бывают разные, в том числе и закрытые, с различными уровнями защищённости и аттестованные для размещения государственных информационных систем, информационных систем обработки персональных данных и для работы с платёжными системами. У нас есть и такие. Вот тут можно детали посмотреть ts-cloud.ru/service/virtualnyi-data-centr-VDC, а еще вот пост моего коллеги про мифы при переезде habr.com/company/technoserv/blog/348982.
Хорошая попытка, но нет!
Я недавно комментировал похожий пост: habr.com/company/activecloudru/blog/415483/#comment_18832225
Отдельно хотелось бы отметить, что с переездом в облако вы теряете контроль над сетью. В своем датацентре вы можете сделать любую конфигурацию, удовлетворяющую вашим условиям и в случае, к примеру, увеличения latency понять где узкое место и исправить ситуацию. В облаке вы можете только пожаловаться поддержке. Когда ситуация будет исправлена (и будет ли исправлена вообще) — вопрос отдельный.
Также остро встает вопрос траффика между регионами. Если у вас свой датацентр вы можете арендовать свой канал и траффик между датацентрами будет ходить по нему. При этом вы сами контролируете ширину канала, а траффик не идет через интернет. В облаке в общем случае это не так.
Отдельно хотелось бы отметить, что с переездом в облако вы теряете контроль над сетью. В своем датацентре вы можете сделать любую конфигурацию, удовлетворяющую вашим условиям и в случае, к примеру, увеличения latency понять где узкое место и исправить ситуацию. В облаке вы можете только пожаловаться поддержке. Когда ситуация будет исправлена (и будет ли исправлена вообще) — вопрос отдельный.
Также остро встает вопрос траффика между регионами. Если у вас свой датацентр вы можете арендовать свой канал и траффик между датацентрами будет ходить по нему. При этом вы сами контролируете ширину канала, а траффик не идет через интернет. В облаке в общем случае это не так.
Построить свой ЦОД очень дорого. Далеко не каждая крупная компания себе может это позволить.
Построить свой цод с нуля — дорого. Арендовать место в готовом цод — гораздо дешевле.
Вы можете арендовать каналы связи между разными облаками и своими офисами, это не отличается от аренды каналов в ЦОДах. Например, некоторые клиенты объединяют свои ресурсы в нашем облаке с облаком Амазона. С российскими операторами ещё проще и дешевле. Я писал об этом в своей статье, это реально работает и не стоит космических денег.
Бекап бекапа главное не забыть!
При переходе на облако можно забыть о безопасности. Вам ни один поставщик услуг не даст гарантий защиты ваших данных. Не страхуют и не возмещают потери связанные с утечкой ваших данных в руки админов или других лиц имеющим доступ к железу на котором находится облако!
А разве с крупными облаками был хоть один подобный случай?
В обычном ДЦ, если он не полностью свой, риски еще выше. Там как минимум сразу понятно из какой стойки оборудование ваше вынимать.
В обычном ДЦ, если он не полностью свой, риски еще выше. Там как минимум сразу понятно из какой стойки оборудование ваше вынимать.
А разве с крупными облаками был хоть один подобный случай?
Вы гарантируете что не было? То что не было огласки не значит что все замечательно.
Нет, не гарантирую конечно, но известных случаев не было.
Если и были, то все получили прекрасную компенсацию и замяли это дело, потому что потеря доверия для такого бизнеса подобна смерти.
Плюс к этому, архитектурно из облака, даже имея доступ во внутренние сети, сложно что-то воровать. Ключи шифрования и данные лежат на разных слоях и доступны разным людям, куча слоев абстракции и т.п.
Да, наверно сотрудник может при острой необходимости и с разрешения службы безопасности попасть на машину, но контролируется это хорошо и уверен что лучше, чем в обычном собственном ДЦ, в котором к слову и так правила весьма и весьма строгие.
Если и были, то все получили прекрасную компенсацию и замяли это дело, потому что потеря доверия для такого бизнеса подобна смерти.
Плюс к этому, архитектурно из облака, даже имея доступ во внутренние сети, сложно что-то воровать. Ключи шифрования и данные лежат на разных слоях и доступны разным людям, куча слоев абстракции и т.п.
Да, наверно сотрудник может при острой необходимости и с разрешения службы безопасности попасть на машину, но контролируется это хорошо и уверен что лучше, чем в обычном собственном ДЦ, в котором к слову и так правила весьма и весьма строгие.
Вы рассматриваете в узком круге интересов. А что если бизнес целиком и полностью зависит от софта в «облаке». В России компенсации, да не шутите. Сколько крупных предприятий за прошлый год отжали? А вы о каких-то данных в облаке. Владелец/директор просто исчезает, падает с окна или убегает за границу оставив все и нет никому дела. Когда крупные куски уже разобраны, то и мелкие идут в расход, кстати пенсионная реформа, повышение налогов, тотальный контроль переписки, контроль платежей, автоматическое взимание денег с зарплат и т.д. — похоже показатель, что мелким не так долго осталось.
Вы же понимаете, что пенсионку за один день не реформируют, а тут сразу после выборов, т.е. в тайне прошли все подготовки и согласования. А люди — это расходник его ставят в известность по мере расхода материала.
Я не за и не против этой власти, я не вижу положительных сдвигов для населения этой страны. А отрицательных полно. Но ничего менять не будут.
Поэтому на облако надейся, а сам не плошай.
И по части компенсации, сколько заплатили торрент-трекеру после уничтожения?
Вы же понимаете, что пенсионку за один день не реформируют, а тут сразу после выборов, т.е. в тайне прошли все подготовки и согласования. А люди — это расходник его ставят в известность по мере расхода материала.
Я не за и не против этой власти, я не вижу положительных сдвигов для населения этой страны. А отрицательных полно. Но ничего менять не будут.
Поэтому на облако надейся, а сам не плошай.
И по части компенсации, сколько заплатили торрент-трекеру после уничтожения?
А с чего Вы решили, что по ТВ или где либо скажут о подобном случае. Мы же говорим о бизнесе. А в России ни на кого надеяться нельзя и тем более, если это связано с денежными потоками. У всех разное понимание зачем облако, а если там все исходные тексты, а как правило скрипты и или базы данных всегда с исходниками.
Россия не правовое государство(любой юрист или адвокат понабравшись опыта сожалеют о том, что пошли работать по данной профессии). И в этом государстве никому ничего не докажете, а заносить бабло нет никакого интереса, проще строиться учитывая эту специфику. И да антисоциальное государство долго ли протянет? Где потом это облако искать.
Россия не правовое государство(любой юрист или адвокат понабравшись опыта сожалеют о том, что пошли работать по данной профессии). И в этом государстве никому ничего не докажете, а заносить бабло нет никакого интереса, проще строиться учитывая эту специфику. И да антисоциальное государство долго ли протянет? Где потом это облако искать.
Главное никогда не забывать что оператор отвечает исключительно SLA. Компенсацию больше месячного платежа обычно никто не даёт. Вы отвечаете своим бизнесом, а провайдер — ежемесячным платежом.
Про «местные» облака лучше вообще даже не начинать. Складывается ощущение, что люди купили железо, поставили лицензированный софт (гипервизоры, SDN, SDS) и никаких проблем самостоятельно решать не научились. Хотя вот с Селектелом и Мэйлом мы ещё не пробовали работать, надо посмотреть.
При выборе провайдера не помешает посмотреть его вакансии. Зачем? А чтобы посмотреть кто будет обслуживать твою инфраструктуру. Вернее сколько им собираются платить. Ведь в большинстве случаев уровень оплаты прямо пропорционален уровню квалификации. Низкие з/п сразу отпугивают от провайдера. Формулировка «з/п не указана» заставляет задуматься. А высокие з/п хоть и не гарантируют, но все же повышают доверие к команде инженеров провайдера.
Мне интересно а те кто пишут что уходя в облако можете забить о безопасности готовы как то бизнесу/собственникам гарантировать ту самую безопасность в своем лице. Не на уровне понятий а как говорится голову на отсечение дать?
Облачный провайдер не несет никаких гарантий сохранности данных. А админ в офисе почки продаст если убьет базу или потерят данные в процессе каких-то манипуляций? Да для собственнника бизнеса наемный сотрудник несет такие же риски что и любой аутсорс.
Облачный провайдер не несет никаких гарантий сохранности данных. А админ в офисе почки продаст если убьет базу или потерят данные в процессе каких-то манипуляций? Да для собственнника бизнеса наемный сотрудник несет такие же риски что и любой аутсорс.
Да, облако это очень дорого, — утверждает кто-то.
А если ему задать вопрос: сколько стоит час простоя бизнеса, что он ответит?
«Не знаю, я не финансист!».
А если ему задать вопрос: сколько стоит час простоя бизнеса, что он ответит?
«Не знаю, я не финансист!».
А сколько стоит час простоя бизнеса, который заплатил (дорого) за облако, а оно (опа!) заработало не так, как ожидали?
Причем при массовой аварии облака достучаться до живого человека с вопросом «где мои данные» невозможно, потому что пытаются сделать хорошо всем клиентам, так что копировать и восстанавливать там сильно больше, чем было у себя в офисе.
Облако хорошо, когда у тебя новый софт, написанный под него. И, да, идеально, когда потребление ресурсов меряется по фактическому значению. А варианты «сервер в облаке с 64 Гб ОЗУ и 200 Гб места диска», который обходится в приличные N денег, даже если на нем вообще никакой нагрузки нет — какой тогда смысл? Да, в таком случае можно добавлять виртуалки по ходу роста нагрузки, но это не так выгодно для клиента, а приложение должно правильно масштабироваться на много нод…
Причем при массовой аварии облака достучаться до живого человека с вопросом «где мои данные» невозможно, потому что пытаются сделать хорошо всем клиентам, так что копировать и восстанавливать там сильно больше, чем было у себя в офисе.
Облако хорошо, когда у тебя новый софт, написанный под него. И, да, идеально, когда потребление ресурсов меряется по фактическому значению. А варианты «сервер в облаке с 64 Гб ОЗУ и 200 Гб места диска», который обходится в приличные N денег, даже если на нем вообще никакой нагрузки нет — какой тогда смысл? Да, в таком случае можно добавлять виртуалки по ходу роста нагрузки, но это не так выгодно для клиента, а приложение должно правильно масштабироваться на много нод…
Да ладно «час простоя», я, обычно, даже ответа на вопрос «сколько у вас активное оборудование датацентра потребляет электричества в сутки» не могу добиться.
До следующего вопроса «А сколько днем/ночью, минимум/максимум» и «сколько электричества потребляют кондиционеры» даже не доходило ни разу, на первом срезаются :)
До следующего вопроса «А сколько днем/ночью, минимум/максимум» и «сколько электричества потребляют кондиционеры» даже не доходило ни разу, на первом срезаются :)
Я точно знаю сколько стоит час простоя — 42 часа простоя это стоимость облачного хостинга для нас в месяц. Можно округлить до 2 суток.
В таком случае вашей конторе облако не нужно.
Просто у некоторых час простоя может стоить как оплата за несколько лет хостинга…
Это образно, а по цифрам: В среднем каждое крупное предприятие (более 500 работников) теряет от простоя своей инфраструктуры 100 тысяч долларов в час или примерно 1666 долларов в минуту.
Просто у некоторых час простоя может стоить как оплата за несколько лет хостинга…
Это образно, а по цифрам: В среднем каждое крупное предприятие (более 500 работников) теряет от простоя своей инфраструктуры 100 тысяч долларов в час или примерно 1666 долларов в минуту.
сервер в облаке с 64 Гб ОЗУ и 200 Гб места диска», который обходится в приличные N денег, даже если на нем вообще никакой нагрузки нет. Это не облако — это колокейшн.
Я заметил 2 интересных современных тренда.
1. Энтузиазм по поводу миграции в облако прямо пропорционален высоте положения и обратно пропорционален практическому техническому опыту. В облака толкают директора и архитекторы. Разработчики, сетевики и опсы стараются аккуратно взывать к здравому смыслу, но получается не всегда.
2. Активировались представители облачных провайдеров, которые глубоко не вдаваясь в технические подробности красочно расписывают, как миграция в облако решит кучу проблем.
Убойная смесь.
1. Энтузиазм по поводу миграции в облако прямо пропорционален высоте положения и обратно пропорционален практическому техническому опыту. В облака толкают директора и архитекторы. Разработчики, сетевики и опсы стараются аккуратно взывать к здравому смыслу, но получается не всегда.
2. Активировались представители облачных провайдеров, которые глубоко не вдаваясь в технические подробности красочно расписывают, как миграция в облако решит кучу проблем.
Убойная смесь.
Мне кажется, что такие статьи больше портят облачным компаниям, так как появляются много грамотных людей в комментариях и говорят правду, а так, продажники смогут напарить кому-то из руководителей, а технорей заставят исполнять, сочтя их протесты за лень.
Sign up to leave a comment.
Что надо забыть админу при переходе на облако — и что подучить