Comments 67
Риски есть всегда и при организации внутреннего проекта, и при переезде в облако.
При закупке оборудования для собственной ИТ-инфраструктуры всегда есть риск потерять потраченные деньги при невостребованности или неполной загрузке этой ИТ-инфраструктуры. Это может произойти по разным причинам, например, самые распространенные:
- Ошибки в расчете потребности и прогнозировании роста вычислительных ресурсов и СХД, когда закупают слишком много и оборудование простаивает
- Ошибки в проектировании инфраструктуры, когда оказывается, что в данной конфигурации решение не работает
- Закрытие проекта внутри компании, под который закупалось оборудование. И если в крупных копаниях иногда есть возможность утилизировать это оборудование под другие проекты, то остальные компании теряют деньги.
- Ошибки при выборе модели оборудования, не всегда заранее известно, что закупаемое оборудование будет работать без ошибок и сбоев. Особенно это относится к новым моделям оборудования или бюджетным вендорам. Это влечет за собой простой и финансовые потери из-за постоянных сбоев и длительного решения проблем вендорской поддержкой.
Всё замечательно строго до того момента, когда приходит РКН/КГБ/НКВД и банит сеть по маске /10 (выносит оборудование).
Всё было замечательно, пока в столб с оптикой для интернета не приехал бульдозерист.
Всё замечательно, пока работает датацентр
Google: "Авария в датацентре" Результатов: примерно 7 130 000
Соответственно вроде и дешевле и выгода сплошная, но вот критичную для бизнес процессов инфраструктуру лучше всё же держать под боком, потому что шанс пострадать за компанию с кем-то всегда есть.
Если открывать ресурсы в итернет из облако, то блокировки тоже можно обойти, например сейчас все пользуются сервисами защиты от DDOS, которые как плюс помогают не замечать блокировок AWS, Microsoft и Google. Как пример, но все может зависеть от архитектуры приложения.
Всё было замечательно, пока в столб с оптикой для интернета не приехал бульдозерист.
Всё замечательно, пока работает датацентр
Так как раз таки облачные провайдеты позволяют вам не бояться этого, используя разные AZ.
Не знаю как обстоят дела в облаке Техносерва, но крупные Cloud-провайдеры позволяют значительно снизить риски.
Насчет выноса оборудования, это да… есть такая проблема, которая никуда не девается если у вас ЦОД под боком.
Это было и раньше и перезагрузка помогала ) но в этот раз не помогло. После обращения в саппорт, саппорт задумался на сутки и потом нам пришло письмо с извинениями, что мол в результате последовательности софтверных и хардверных ошибок ваши данные потерялись) и вообще рекомендуем вам регулярно бэкапиться )
Это было тестовое окружение и разумеется был, но был как водится на том же диске )
Восстановление работы окружения заняло три дня) данные взяли с другого тестевого окружения, и потом пришлось сервера приложений перенастраивать, не сильно много, но от графика мы отстали.
Это заставило меня задуматься что же значат, те самые три девятки после запятой по доступности сервиса, которые обещает кладут провайдер.
Что вообще можно с провайдера потребовать, если данные потерялись по их вине. И после изучения соглашения об уровне сервиса оказалось… что ничего нельзя потребовать) никакие штрафы или бенефиты не предусмотрены, если уровень сервиса оказался не такой как обещано.
То есть в целом провайдер вам ничем не обязан, а цифры по уровню доступности сервиса, это просто маркетинговые материалы.
Я для себя сделал вывод, что продакшн в Клауде можно разворачивать, только если данные в нем не нужны, а например трёхдневный простой развёрнутой системы никак (или почти никак) не повлияет на Ваш бизнес.
Вот такое мое скромное мнение, никак не претендующее на истину в последней инстанции)
1. Совсем не обязательно закладываться на дорогие комплектующие. Б/у серверов с новыми дисками часто хватает на 5+ лет выше крыши. Тот же 'монстр' Гугл не гнушается такими решениями совершенно.
2. Можно выносить обслуживание и настройку в аут-сорс, совсем не обязательно самим делать всё.
3. Про риски уже сказали. Хорошо, пока всё хорошо. Но когда завтра из кабеля по какой-то причине не будет торчать ваши 17 тер, что будете делать? Лезгинку плясать? Своё под боком можно исправить ВСЕГДА (ок, кроме пожара, ладно).
Потом не стоит забывать про тот же OpenStack.
В общем картина нарисована таким образом, чтоб показать выгодность облака. Для каких-то компаний этот расчёт будет справедливым, но далеко не для всех.
Если сервера брендовые типа HP — скорее всего цифра будет 1%.
Львиная доля времени уходит на настройку ОС, настройку бекапов, обновление ОС, настройка фаервола(ов), работа с пользователями и их ПК, следить/настраивать прикладное ПО.
Облака все эти задачи не решают.
плюс «забыли» посчитать редандант линии на 1/10Г до этого облака (директ коннеткы там, экспресс роуты), или оно через публичный интернет? :-)
ФОТ на эксплуатацию облачного решения содержится в тарифах на облако. Причем, как известно, при масштабировании облака затраты на эксплуатацию растут не прямо пропорционально. Кроме того квалификация СЭ и автоматизация системы управления облачного оператора позволяет в широких диапазонах наращивать мощности облака при несущественном росте ФОТа.
Приведенный в статье кейс посчитан с учетом того, что доступ к облаку осуществляется через публичный Интернет. Средство VMware NSX позволяет настраивать Ipsec VPN поверх Интернета.
Мы предоставляем клиенту инфраструктуру как услугу – IaaS, настройку ОС и ПО клиент делает самостоятельно. Если у клиента нет таких компетенций, то настройку и поддержку ОС и ПО можем взять на себя, но это дополнительные услуги, в данном кейсе их нет.
полосы, задержки, надежность это все гарантирует?
если мы строим полную аналогию — ок
выделенная линия 1/10G резервированная до датацентра провайдера
выделенный купленный спец канал до облака (express route (Azure), Direct Connect (AWS), прочие директы для остальных клаудов, ну или выделенный линк с гарантированным качеством/полосой/летенси до используемого клауд облака), естественно резервированный
и да резервный это не 2 линка — а два линка по разным путям если что (что тоже обычно увеличивает стоимость)
это если одна площадка
и конечно оплата чей-то работы на запуск и поддержку этого всего чумудана
это только сетевка
из плюсов — разве что опекс, и то нужно считать когда он перекрывает реальные (а не раздутые) затраты заказчика в случае онпремис
P.S. я за клауд если что, чем больше народу туда переползает — тем больше я зарабатываю 5-)
Единственный момент, я попрошу вас и остальных участников обсуждения не путать ФОТ и ЗП. Чтобы получить из ФОТ ЗП на руки нужно ФОТ поделить на 1.5 (это грубая оценка).
«грамотный инженер» за 100k в месяц соберёт более производительную и оптимизированную под конкретные задачи клиента систему на железе от «дешманского» Supermicro с парой запасных узлов и резервированием СХД в 2 раза дешевле
В сравнении вендорских СХД и тех, которые можно построить самостоятельно на базе того же Supermicro, не все так однозначно.
Например, вендорская СХД: 2 контроллера, куча RAM кэша, рабочие dedup/compression, thin volumes, различные программные прослойки для удобства управления дисками, массивами и т.д.
Чтобы построить что-то хоть немного аналогичное: нужно 2x сервера c HBA и производительными CPU, шареный jbod, подключенный к головам по SAS, различная мелочевка для коммутации этого всего, ну и, собственно, SAS диски (SAS-SSD от любого вендора будут не дешевыми). По программной части будет что-нибудь типа: mdadm — lvm — iscsi_target. По итогу: нету RAM кэша (мы же не можем рисковать, с отдельным сервером может случиться что угодно), нету dedup/compression, с mdadm+lvm нельзя добиться такой гибкости и такого функционала, какой есть в вендорских СХД (пример). При этом по цене не факт, что получится дешевле, особенно вместе с SAS-SSD дисками.
Альтернативой может быть ceph, но его грамотная поддержка потребует больше ресурсов и более квалифицированный персонал чем первые 2 варианта. Желательно разбираться в кодовой базе ceph, возможно понадобится вносить правки, тестировать все это.
Примерный порядок розничных цен для стандартных компонентов я привёл ниже.
Так нужны SAS SSD, чтобы все диски были доступны с 2ух «голов» СХД для возможности online переезда RAID'а (если мы хотим получить аналогичное вендорскому решение). А они будут намного дороже, особенно если схожих с Optane характеристик. В случае с SATA дисками кроме RAID'а нужен будет еще механизм синхронной репликации, а это сразу просадка по производительности, и уже сравнивать с вендорской 2ух котроллерной СХД нельзя.
против одиночной «брендовой»
Так не одиночная же. Обычно берут 2ух контроллерную, а это аналог 2ух узлов в самодельном SAN'е.
мы получим стоимость более чем в 2 раза меньше
Вот как раз если попытаться повторить один в один вендорскую СХД (например какую-нибудь OceanStor Dorado5000 V3) с близки показателями по iops, latency, доступности, то будет сопоставимо по цене (заоблочные цены из статьи не рассматриваем), но при этом может быть меньшая функциональность (тот же dedup мало где нормально работает, да еще чтобы без просадки по производительности).
СХД: 2 контроллера, куча RAM кэша, рабочие dedup
...
Чтобы построить что-то хоть немного аналогичное
Купив лицензию на StarWind HA ( про SAS «диски» не уверен, но не совсем «эконом класс»: RAID10, SCSI с «батарейкой» и SSD Cache, 10Gb Eth)
«грамотный инженер»... соберёт... производительную и оптимизированную под конкретные задачи клиента систему на железе от... Supermicro«2-х узловую резервированную СХД» на 30% дешевле ( а в сравнении с 3PAR — будет ещё больший отрыв)
P.S. «Грамотные инженеры» по «сети», и по «железу» СХД — мои коллеги
Я, «грамотный инженер» который успешно эксплуатировал комплект как СХД для Hyper-V кластера ( к слову, Hyper-V — ещё один пункт экономии)
P.P.S. Кстати, это 3/5-тых Ж-) ИТ-подразделения
Купив лицензию на StarWind HA
Это, как и ceph — распределнное программно определяемое хранилище, т.е. другой тип решений. Обсуждалась же классическая централизованная блочная СХД.
«2-х узловую резервированную СХД» на 30% дешевле
Резервированную? Т.е. поверх будет еще синхронная репликация? Тогда это, опять же, другой тип решений с другим показателем производительности. Обсуждалась реализация аналога 2ух котроллерной СХД, когда каждый узел одновременно видит все диски из jbod. Диски для этого должны быть с SAS интерфейсом (по path на каждый узел СХД) и jbod, подключенный по SAS одновременно к 2ум узлам. В этом случае мы одновременно используем 2 узла, балансируем между ними нагрузку (каждый держит разные raid'ы, раздает разные луны), и при этом не нужна никакая ухудшающая производительность репликация. Тут по ценнику может быть тоже самое, но при этом меньше функционала (который не всегда, конечно, нужен), отсутствие кэша (аппаратный raid с батарейкой и кэшем не подойдет, т.к. с ним не реализовать 2ух узловой режим работы без доп. механизмов репликации).
О NVMe и говорить не нужно, в этом случае аналог 2ух контроллерной вендорской СХД особо собрать и не получится (как диски по PCIe одновременно на 2 сервера пробрасывать).
Я, «грамотный инженер» который успешно эксплуатировал комплект как СХД
Имеются в эксплуатации всевозможные типы SAN: самодельные на базе supermicro без репликации (2x 2U head, lsi hba, Nx 4U jbods via sas, software: mdadm,lvm,scst_target), самодельные на базе supermicro c репликацией (2x 4U head, lsi hba, software: drbd, mdadm,lvm,scst_target), различные вариации вышеперечисленного, различные вендорские СХД. Конечно, 2x 4U Supermicro сервера с drbd репликацией будут в разы дешевле стоить готовой СХД, ну так и производительность будет совсем другая. При приближении функционала сравнивается и цена.
NVMe — согласен, сегодня решающий фактор
Поэтому почему бы и не рассмотреть PetaSAN? MS Storage Spaces Direct (S2D)?
( «Аналог 2ух контроллерной СХД, когда каждый узел одновременно видит все диски из jbod», но не LSI и не *nix, — тоже эксплуатировал. Выразимся так: Starwind HA показал себя лучше, более удобным)
СХД от HPE этот наш «грамотный инженер» за 100k в месяц соберёт более производительную и оптимизированную под конкретные задачи клиента систему на железе от «дешманского» Supermicro
Я просчитывал подобный подход. Пришёл к тому, что тот же SM с HPE по ценам сопоставим. Тогда уж смотреть в сторону какого-нибудь Dell. Он действительно дешевле, а вот по качеству лучше. Ремарка. Последние SM не пробовал, но все предыдущие решения 2005-2013 мне не понравились совершенно. Мелкая неприятность, но досадная, например — ломается пластик сазалок винта в корзине. Итог — пластиковая панель в руке, винт в корзине.
Мы много раз считали. На короткую облако дешевле, а вот в горизонте 3-5 лет — в разы дороже выходи
Сделайте лучше вебинар по расчету — было бы здорово послушать, позадавать вопросы как считается, какие расходы, какие SLA.
Такие планы у нас есть. Обычно анонсы о вебинарах публикуются в ленте новостей в группе в Facebook или на нашем сайте.
Клиент имеет скидку у вендора Hewlett Packard 25%.
Странная формулировка при учете, что отдельные позиции в прайсе имеют разный процент скидки, даже те же серверы лучше дискаунтируются, чем описано, не говоря уже об СХД.
В расчетах приведено 5 серверов, а считают VC на полное шасси, что не является особо корректным. Понятно что нельзя купить часть портов, но и докупая серверы, тратиться на VC не нужно будет. Да и говоря об 1 корзине целесообразность наличия VC вызывает сомнения…
Для чего посчитаны отдельно еще 2 коммутатора (непонятно каких), если VC может Direct-Attach к 3PAR?
3PAR 8400 взят на 18TB — не слишком ли жирно?
Что такое ПО для работоспособности СХД, если у 3PAR сейчас лицензии все включены в поставку?
Ведь в облако вы перевозите только «стойку с серверами», а это далеко не вся it инфраструктура заказчика.
2)Затраты на обслуживание своей стойки у вас в расчетах дублируются. Указывайте что-то одно — либо расширенную гарантию, либо стоимость обслуживания
3) Плюс мы сразу добавляем к ОРЕХу стоимость возросших каналов между офисом и облаком.
4) Покупая новое железо у HP по GPL еще и с расширенной гарантией я покупаю новое железо с расширенной гарантией. А вот переезжая в облако — в качестве основы я получаю б/у сервера и неизвестно какие диски в СХД (хотя в случае со своим решением вы разумеется посчитали самые дорогие для увеличения CAPEX)
Вкратце — хранить железо у себя невыгодно, это большие минусы, переезжайте к нам мы храним железо у себя и внезапно это оказывается выгодно (нам) (с)
Хорошая попытка, но нет
Стоимость спецификации клиенту тоже Техносерв считал? Можно только посочуствовать доверию клиента интегратору, кем бы он ни был.
На месте CFO я бы сильно наказал закуперов за 25% на такой сумме контракта (HP судя по статье не первый раз покупают).
И да "и ящик водки обратно". В смысле свои железки.
Собственнное ИТ-решение 721 тыс/мес
Облачная услуга 606 тыс/мес
О чём вторая половина статьи? Ведь облачное выгоднее.
На мой взгляд, на 5 серверов и 17 ТБ, в ряде случаев хватит и MSA2xxx, а если в расчетах имеется в виду all flash массив — то это надо указывать т.к. сильно влияет на цену как железа так и облака.
1. Экономика в РФ везде по разному не стабильная, что будет если сейчас денег выделили а на следующий год нет или мало/меньше? Отдельный вопрос кстати фиксации цены на облако в РФ, я имею в виду валюта и условия изменения (повышения :) ) цен.
2. Учитывая п1 и то, что 2006-7 год давно позади и денег не много, я не думаю что сервера выкидываются через 5 лет эксплуатации если с ними все порядке следовательно считать 5 лет не совсем корректно. Мне кажется что в РФ скорее дефицит железа чем избыток, следовательно для старого сервака задачу найдут.
3. Непрозрачность в реалиях РФ просто шкалящая: кто и когда имеет доступ к оборудованию (включая силовые структуры)? Какая цепочка услуг-посредников-субподрядчиков контракта? Какое оборудование используется в облаке и есть ли на него контракты сервисные?
4. Вообще у меня есть сомнения относительно качества услуг наших Мега облаков, в Амазоне круто что если мне нужно к концу квартала какую то специфичную считалку для репортов которая будет работать с особенными пиками нагрузки — я ее закажу и заплачу ровно до копейки за то сколько минут она работала. Насколько API, например техносерва, такую оркестрацию предоставляет, а тарифы гибкость — я не знаю. И также касаемо надежности/DR — хочу иметь гео кластер — галку жмакнул и получил, для энтерпрайза это важно.
Вообще расчет сделан по лекалам США/Европа НО у них на стороне заказчиков: стабильность валюты, стабильность-прогнозируемость экономики, очень высокая цены персонала; а на другой стороне Азур, AWS и Google которые во первых режут косты в глобальных масштабах, а во вторых не покупают стораджи 3par для своих облаков.
Вот посмотрите всерьез, кто из ентерпрайзов в РФ планирует реальный бюджет на 5 лет? Государство живет в однолетнем бюджете.
>В облаке можно арендовать лицензии Microsoft (или программные услуги) и не закупать лицензии на годы вперёд, а оплачивать по фактическому использованию ежемесячно.
В последние года, ~ с 2014 года, почти все корпораты сидят на подписках на ПО и ОС на 3 года с возможностью проводить перерасчёт в большую сторону когда нужно. И прекрасно его размещают на своих железках.
— 17Гб СХД — это слезы.
Долго писать не хочется… если нужно действительно объемное хранилище — облако в пролете, там хорошие цены только при небольших объемах. Канал связи — еще одна точка отказа, если постоянно льются данные изнутри компании и обратно — то облако в пролете. Я уже не говорю про кучу вопросов по безопасности, которая может стоить сильно дороже всей этой груды железа и ФОТ одного админа (который к слову может параллельно заниматься многими другими полезными для бизнеса вещами).
Есть еще куча «но», почему большие компании нередко предпочитают свои ЦОДы и даже отказываются от облаков. А вот для малого бизнеса — таки да, это выгодно.
Облаком ни кто не будет управлять?
Разовый платеж, как то странно что его нет, а кто тогда будет настраиваться вся инфраструктура — сеть, сервера и тд?
Виртуализация VMware: vCPU — 325; RAM — 1 526 Гб, HDD — 12 250 Гб. — это один сервер, не думаю, это целая инфраструктура и ее нужно будет спланировать, настроить, что-то туда перенести из существующей инфраструктуры, при этом учесть простои и тд.
ФОТ ИТ персонала 104 тыс в месяц – это экспертная оценка затрат только на поддержку проекта, переносимого в облако. Фактически это 1 системный администратор, который поддерживает несколько проектов клиента, включая переносимый в облако, и обладающий навыками работы в vCloud Director.
Расходы на управление облаком со стороны сервис провайдера заложены в тарифы на облако.
Разового платежа нет, потому что инфраструктура для клиента разворачивается в публичном облаке, облако уже сконфигурировано и настроено таким образом, что дополнительно не требуется делать большого количества настроек под каждого клиента.
Своими виртуальными ресурсами в облаке клиент управляет самостоятельно: конфигурирование виртуальных машин и сетей, настройка IPsecVPN и т.д. Затраты со стороны клиента на проектирование инфраструктуры, настройку, планирование миграции и саму миграцию не включены в кейс, потому что они есть у клиента в обоих случаях.
А куда делись 37 миллионов? Почему только Opex сокращен? Вместо там 700тыс в месяц, компания получает все хотелки за 600 тыс в месяц, при этом не тратит 37 лимонов?
Под собственным решением понимается in-hous решение, которое клиент закупает, полностью им владеет и самостоятельно управляет. Решение размещается в серверной клиента или его ЦОДе. ФОТ в этой колонке указан на собственный ИТ-персонал клиента. В данном случае клиент посчитал, что у него есть сотрудник, который переиспользуется на несколько проектов, знакомый с администрированием VMware. Как раз в этом случае и есть риск, что этот один сотрудник в какой-то момент времени может оказаться некомпетентным в каком-либо вопросе или сильно перегруженным. Может потребоваться его дополнительное обучение или привлечение дополнительного персонала, что влечет за собой дополнительные расходы для компании.
Единоразовых расходов 38 575 млн. руб. в случае использования облачной услуги у клиента нет, потому что он приобретает ИТ-инфраструктуру на облачной платформе и ежемесячно платит только за использование этой инфраструктуры. В этом случае ему не требуется закупать оборудование на несколько лет вперед.
Да, к этому не забудет ФОТ своих спецов добавить (это мы оплачиваем просто вынос стойки в ДЦ и аренду железа) и канал до ДЦ, но это более понятно для всех — и для админов, и для бизнеса.
Скажем, к этой СХД подходят SAS-диски HP K2P94B ёмкостью 1,8ТБ. Возьмём 20 штук, RAID10, ёмкость 18ТБ.
Вот предложение на них по 118 т.р.: itb2bgroup.ru/zhestkiy-disk-hp-k2p94b-1-8-tb-10520-rpm-sas-2-5--hdd
Вот зарубежный магазин — по 560 долларов: www.serversupply.com/HARD%20DRIVES%20W-TRAY/SAS-12GBPS/1.8TB-10000RPM/HPE/K2P94B.htm
Вот ещё один, по 400: storagepartsdirect.com/hpe-storeserv-8000-k2p94b-1-8tb-10krpm-2-5inch-sas-12gbps-3par-hdd
Лично я пару лет назад покупал сравнимые 900ГБ SAS-диски Леново для СХД по 400$ за штуку. Хорошо, с учётом того, что цена на такие комплектующие может сильно меняться в зависимости от условий поставки, положим 200т.р. за диск, итого — 4 миллиона за 20 дисков. Ещё, скажем, миллион на саму СХД. Полки расширения не нужны. Кое-что нужно на всякие дополнительные вещи вроде интерфейсных модулей и опциональных лицензий. И всё равно, как вы насчитали 17 с лишним миллионов?
Закупка железа против облака: как правильно считать