Комментарии 67
В статье нет затрат на риски, а они самые дорогие.
Риски есть всегда и при организации внутреннего проекта, и при переезде в облако.
При закупке оборудования для собственной ИТ-инфраструктуры всегда есть риск потерять потраченные деньги при невостребованности или неполной загрузке этой ИТ-инфраструктуры. Это может произойти по разным причинам, например, самые распространенные:
- Ошибки в расчете потребности и прогнозировании роста вычислительных ресурсов и СХД, когда закупают слишком много и оборудование простаивает
- Ошибки в проектировании инфраструктуры, когда оказывается, что в данной конфигурации решение не работает
- Закрытие проекта внутри компании, под который закупалось оборудование. И если в крупных копаниях иногда есть возможность утилизировать это оборудование под другие проекты, то остальные компании теряют деньги.
- Ошибки при выборе модели оборудования, не всегда заранее известно, что закупаемое оборудование будет работать без ошибок и сбоев. Особенно это относится к новым моделям оборудования или бюджетным вендорам. Это влечет за собой простой и финансовые потери из-за постоянных сбоев и длительного решения проблем вендорской поддержкой.
Всё как-то волшебно получается, только где у нас такие огромные холдинги в стране, готовые выкладывать разово по 26 лямов только на оборудование? Ситуация 1 (реальная). Друг рассказывал, пригласили его на должность админа в такой крупный холдинг. После того, как увидел поросшие мхом древние серваки и пообщавшись с сотрудниками, что от него ожидают и что готовы предложить по условиям работы (не оплаты, а именно рабочих моментов), развернулся, и крестясь левой ногой, свалил побыстрее с той конторы. Это один момент. Ситуация 2 (возможная). Переехали дружно в «облака», радостно работаем какое-то время, а потом рядом с нашим офисом начинается стройка и случайно рвётся кабель Интернетов. Сидим, курим бамбук. Ситуация 3 (тоже реальная). Работаем долго и плодотворно с облачным провайдером. А в один «прекрасный» день он, вместе с «облаком» исчезает на 3 дня. И таких рисков можно смоделировать не один десяток.
Всё замечательно строго до того момента, когда приходит РКН/КГБ/НКВД и банит сеть по маске /10 (выносит оборудование).
Всё было замечательно, пока в столб с оптикой для интернета не приехал бульдозерист.
Всё замечательно, пока работает датацентр
Google: "Авария в датацентре" Результатов: примерно 7 130 000
Соответственно вроде и дешевле и выгода сплошная, но вот критичную для бизнес процессов инфраструктуру лучше всё же держать под боком, потому что шанс пострадать за компанию с кем-то всегда есть.
Если использовать облако чисто для внутренних нужд, как расширение собственной инфраструктуры — то никто не забанит. (на примере AWS, оно само будет к вам подключаться по VPN)
Если открывать ресурсы в итернет из облако, то блокировки тоже можно обойти, например сейчас все пользуются сервисами защиты от DDOS, которые как плюс помогают не замечать блокировок AWS, Microsoft и Google. Как пример, но все может зависеть от архитектуры приложения.
Так как раз таки облачные провайдеты позволяют вам не бояться этого, используя разные AZ.
Не знаю как обстоят дела в облаке Техносерва, но крупные Cloud-провайдеры позволяют значительно снизить риски.
Насчет выноса оборудования, это да… есть такая проблема, которая никуда не девается если у вас ЦОД под боком.
Если открывать ресурсы в итернет из облако, то блокировки тоже можно обойти, например сейчас все пользуются сервисами защиты от DDOS, которые как плюс помогают не замечать блокировок AWS, Microsoft и Google. Как пример, но все может зависеть от архитектуры приложения.
Всё было замечательно, пока в столб с оптикой для интернета не приехал бульдозерист.
Всё замечательно, пока работает датацентр
Так как раз таки облачные провайдеты позволяют вам не бояться этого, используя разные AZ.
Не знаю как обстоят дела в облаке Техносерва, но крупные Cloud-провайдеры позволяют значительно снизить риски.
Насчет выноса оборудования, это да… есть такая проблема, которая никуда не девается если у вас ЦОД под боком.
Был у меня такой случай. На одном из тестовых окружений, развёрнутом на Амазоне, отпал EBS диск от сервера БД.
Это было и раньше и перезагрузка помогала ) но в этот раз не помогло. После обращения в саппорт, саппорт задумался на сутки и потом нам пришло письмо с извинениями, что мол в результате последовательности софтверных и хардверных ошибок ваши данные потерялись) и вообще рекомендуем вам регулярно бэкапиться )
Это было тестовое окружение и разумеется был, но был как водится на том же диске )
Восстановление работы окружения заняло три дня) данные взяли с другого тестевого окружения, и потом пришлось сервера приложений перенастраивать, не сильно много, но от графика мы отстали.
Это заставило меня задуматься что же значат, те самые три девятки после запятой по доступности сервиса, которые обещает кладут провайдер.
Что вообще можно с провайдера потребовать, если данные потерялись по их вине. И после изучения соглашения об уровне сервиса оказалось… что ничего нельзя потребовать) никакие штрафы или бенефиты не предусмотрены, если уровень сервиса оказался не такой как обещано.
То есть в целом провайдер вам ничем не обязан, а цифры по уровню доступности сервиса, это просто маркетинговые материалы.
Я для себя сделал вывод, что продакшн в Клауде можно разворачивать, только если данные в нем не нужны, а например трёхдневный простой развёрнутой системы никак (или почти никак) не повлияет на Ваш бизнес.
Вот такое мое скромное мнение, никак не претендующее на истину в последней инстанции)
Это было и раньше и перезагрузка помогала ) но в этот раз не помогло. После обращения в саппорт, саппорт задумался на сутки и потом нам пришло письмо с извинениями, что мол в результате последовательности софтверных и хардверных ошибок ваши данные потерялись) и вообще рекомендуем вам регулярно бэкапиться )
Это было тестовое окружение и разумеется был, но был как водится на том же диске )
Восстановление работы окружения заняло три дня) данные взяли с другого тестевого окружения, и потом пришлось сервера приложений перенастраивать, не сильно много, но от графика мы отстали.
Это заставило меня задуматься что же значат, те самые три девятки после запятой по доступности сервиса, которые обещает кладут провайдер.
Что вообще можно с провайдера потребовать, если данные потерялись по их вине. И после изучения соглашения об уровне сервиса оказалось… что ничего нельзя потребовать) никакие штрафы или бенефиты не предусмотрены, если уровень сервиса оказался не такой как обещано.
То есть в целом провайдер вам ничем не обязан, а цифры по уровню доступности сервиса, это просто маркетинговые материалы.
Я для себя сделал вывод, что продакшн в Клауде можно разворачивать, только если данные в нем не нужны, а например трёхдневный простой развёрнутой системы никак (или почти никак) не повлияет на Ваш бизнес.
Вот такое мое скромное мнение, никак не претендующее на истину в последней инстанции)
Несколько замечаний.
1. Совсем не обязательно закладываться на дорогие комплектующие. Б/у серверов с новыми дисками часто хватает на 5+ лет выше крыши. Тот же 'монстр' Гугл не гнушается такими решениями совершенно.
2. Можно выносить обслуживание и настройку в аут-сорс, совсем не обязательно самим делать всё.
3. Про риски уже сказали. Хорошо, пока всё хорошо. Но когда завтра из кабеля по какой-то причине не будет торчать ваши 17 тер, что будете делать? Лезгинку плясать? Своё под боком можно исправить ВСЕГДА (ок, кроме пожара, ладно).
1. Совсем не обязательно закладываться на дорогие комплектующие. Б/у серверов с новыми дисками часто хватает на 5+ лет выше крыши. Тот же 'монстр' Гугл не гнушается такими решениями совершенно.
2. Можно выносить обслуживание и настройку в аут-сорс, совсем не обязательно самим делать всё.
3. Про риски уже сказали. Хорошо, пока всё хорошо. Но когда завтра из кабеля по какой-то причине не будет торчать ваши 17 тер, что будете делать? Лезгинку плясать? Своё под боком можно исправить ВСЕГДА (ок, кроме пожара, ладно).
НЛО прилетело и опубликовало эту надпись здесь
Думаю, что ФОТ на it персонал в «облачной услуге» тоже стоит заложить.
Потом не стоит забывать про тот же OpenStack.
В общем картина нарисована таким образом, чтоб показать выгодность облака. Для каких-то компаний этот расчёт будет справедливым, но далеко не для всех.
Потом не стоит забывать про тот же OpenStack.
В общем картина нарисована таким образом, чтоб показать выгодность облака. Для каких-то компаний этот расчёт будет справедливым, но далеко не для всех.
да да, а потом и вовсе, окажется что штатный админ со знанием ажура и авс окажется на 30-50% дороже…
Повесьте на админа еще пару-тройку IT-related обязанностей, чтобы было, чем его занять в свободное от безделья время и, внезапно, «окажется что штатный админ со знанием ажура и авс окажется на 30-50% ДЕШЕВЛЕ»
Напишите список типичных задач админа за месяц и проставьте трудозатраты в человеко часах. Вряд ли там будет больше 5% на решение задач с серверным железом.
Если сервера брендовые типа HP — скорее всего цифра будет 1%.
Львиная доля времени уходит на настройку ОС, настройку бекапов, обновление ОС, настройка фаервола(ов), работа с пользователями и их ПК, следить/настраивать прикладное ПО.
Облака все эти задачи не решают.
Если сервера брендовые типа HP — скорее всего цифра будет 1%.
Львиная доля времени уходит на настройку ОС, настройку бекапов, обновление ОС, настройка фаервола(ов), работа с пользователями и их ПК, следить/настраивать прикладное ПО.
Облака все эти задачи не решают.
Как изящно и красиво выкинут ФОТ из облачного решения.
плюс «забыли» посчитать редандант линии на 1/10Г до этого облака (директ коннеткы там, экспресс роуты), или оно через публичный интернет? :-)
плюс «забыли» посчитать редандант линии на 1/10Г до этого облака (директ коннеткы там, экспресс роуты), или оно через публичный интернет? :-)
ФОТ на эксплуатацию облачного решения содержится в тарифах на облако. Причем, как известно, при масштабировании облака затраты на эксплуатацию растут не прямо пропорционально. Кроме того квалификация СЭ и автоматизация системы управления облачного оператора позволяет в широких диапазонах наращивать мощности облака при несущественном росте ФОТа.
Приведенный в статье кейс посчитан с учетом того, что доступ к облаку осуществляется через публичный Интернет. Средство VMware NSX позволяет настраивать Ipsec VPN поверх Интернета.
НЛО прилетело и опубликовало эту надпись здесь
IPSec over Intentet, really?
полосы, задержки, надежность это все гарантирует?
если мы строим полную аналогию — ок
выделенная линия 1/10G резервированная до датацентра провайдера
выделенный купленный спец канал до облака (express route (Azure), Direct Connect (AWS), прочие директы для остальных клаудов, ну или выделенный линк с гарантированным качеством/полосой/летенси до используемого клауд облака), естественно резервированный
и да резервный это не 2 линка — а два линка по разным путям если что (что тоже обычно увеличивает стоимость)
это если одна площадка
и конечно оплата чей-то работы на запуск и поддержку этого всего чумудана
это только сетевка
из плюсов — разве что опекс, и то нужно считать когда он перекрывает реальные (а не раздутые) затраты заказчика в случае онпремис
P.S. я за клауд если что, чем больше народу туда переползает — тем больше я зарабатываю 5-)
полосы, задержки, надежность это все гарантирует?
если мы строим полную аналогию — ок
выделенная линия 1/10G резервированная до датацентра провайдера
выделенный купленный спец канал до облака (express route (Azure), Direct Connect (AWS), прочие директы для остальных клаудов, ну или выделенный линк с гарантированным качеством/полосой/летенси до используемого клауд облака), естественно резервированный
и да резервный это не 2 линка — а два линка по разным путям если что (что тоже обычно увеличивает стоимость)
это если одна площадка
и конечно оплата чей-то работы на запуск и поддержку этого всего чумудана
это только сетевка
из плюсов — разве что опекс, и то нужно считать когда он перекрывает реальные (а не раздутые) затраты заказчика в случае онпремис
P.S. я за клауд если что, чем больше народу туда переползает — тем больше я зарабатываю 5-)
НЛО прилетело и опубликовало эту надпись здесь
В случае с облаком у них нет ИТ персонала в расчете от слова совсем.
Единственный момент, я попрошу вас и остальных участников обсуждения не путать ФОТ и ЗП. Чтобы получить из ФОТ ЗП на руки нужно ФОТ поделить на 1.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 мало где нормально работает, да еще чтобы без просадки по производительности).
( по Ceph — можно попробовать PetaSAN )
Купив лицензию на StarWind HA ( про SAS «диски» не уверен, но не совсем «эконом класс»: RAID10, SCSI с «батарейкой» и SSD Cache, 10Gb Eth)
P.S. «Грамотные инженеры» по «сети», и по «железу» СХД — мои коллеги
Я, «грамотный инженер» который успешно эксплуатировал комплект как СХД для Hyper-V кластера ( к слову, Hyper-V — ещё один пункт экономии)
P.P.S. Кстати, это 3/5-тых Ж-) ИТ-подразделения
СХД: 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 репликацией будут в разы дешевле стоить готовой СХД, ну так и производительность будет совсем другая. При приближении функционала сравнивается и цена.
Что мешает взять двухголовую систему от того же supermicro? Софт — Windows Storage Server в комплекте, залит уже предварительно настроенным. Это линейка Storage Bridge Bay. SAS, балансировка нагрузки, дедупликация и всё прочее есть.
Всё-таки, мы обсуждаем как избежать, например, "«оригинальных» SAS-дисков от HPE за $900 штучка" и/или 3PAR StoreServ 8400 ( возможно, для 17Tb «крупного агрохолдинга» подойдёт и одна из «младших» линеек)
NVMe — согласен, сегодня решающий фактор
Поэтому почему бы и не рассмотреть PetaSAN? MS Storage Spaces Direct (S2D)?
( «Аналог 2ух контроллерной СХД, когда каждый узел одновременно видит все диски из jbod», но не LSI и не *nix, — тоже эксплуатировал. Выразимся так: Starwind HA показал себя лучше, более удобным)
NVMe — согласен, сегодня решающий фактор
Поэтому почему бы и не рассмотреть PetaSAN? MS Storage Spaces Direct (S2D)?
( «Аналог 2ух контроллерной СХД, когда каждый узел одновременно видит все диски из jbod», но не LSI и не *nix, — тоже эксплуатировал. Выразимся так: Starwind HA показал себя лучше, более удобным)
НЛО прилетело и опубликовало эту надпись здесь
Поправка. В LVM давно уже реализовано практически всё то же, что и в mdadm,
СХД от HPE этот наш «грамотный инженер» за 100k в месяц соберёт более производительную и оптимизированную под конкретные задачи клиента систему на железе от «дешманского» Supermicro
Я просчитывал подобный подход. Пришёл к тому, что тот же SM с HPE по ценам сопоставим. Тогда уж смотреть в сторону какого-нибудь Dell. Он действительно дешевле, а вот по качеству лучше. Ремарка. Последние SM не пробовал, но все предыдущие решения 2005-2013 мне не понравились совершенно. Мелкая неприятность, но досадная, например — ломается пластик сазалок винта в корзине. Итог — пластиковая панель в руке, винт в корзине.
Это правильные цифры? Чтобы разместить менее 18 ТБ (12 дисков по 3 ТБ в RAID 1) нужно чуть менее 18 млн рублей? По миллиону на терабайт? Я нигде порядок не потерял?
Мы много раз считали. На короткую облако дешевле, а вот в горизонте 3-5 лет — в разы дороже выходи
Описаны разумные вещи — но убедить так текстом не достаточно.
Сделайте лучше вебинар по расчету — было бы здорово послушать, позадавать вопросы как считается, какие расходы, какие SLA.
Сделайте лучше вебинар по расчету — было бы здорово послушать, позадавать вопросы как считается, какие расходы, какие SLA.
Такие планы у нас есть. Обычно анонсы о вебинарах публикуются в ленте новостей в группе в Facebook или на нашем сайте.
НЛО прилетело и опубликовало эту надпись здесь
Клиент имеет скидку у вендора Hewlett Packard 25%.
Странная формулировка при учете, что отдельные позиции в прайсе имеют разный процент скидки, даже те же серверы лучше дискаунтируются, чем описано, не говоря уже об СХД.
В расчетах приведено 5 серверов, а считают VC на полное шасси, что не является особо корректным. Понятно что нельзя купить часть портов, но и докупая серверы, тратиться на VC не нужно будет. Да и говоря об 1 корзине целесообразность наличия VC вызывает сомнения…
Для чего посчитаны отдельно еще 2 коммутатора (непонятно каких), если VC может Direct-Attach к 3PAR?
3PAR 8400 взят на 18TB — не слишком ли жирно?
Что такое ПО для работоспособности СХД, если у 3PAR сейчас лицензии все включены в поставку?
1) Как замечательно выкинут ФОТ из облачного решения. А пусконаладкой/обслуживанием в течении обговоренных 5 лет оставшуюся клиентскую инфраструктуру кто будет?
Ведь в облако вы перевозите только «стойку с серверами», а это далеко не вся it инфраструктура заказчика.
2)Затраты на обслуживание своей стойки у вас в расчетах дублируются. Указывайте что-то одно — либо расширенную гарантию, либо стоимость обслуживания
3) Плюс мы сразу добавляем к ОРЕХу стоимость возросших каналов между офисом и облаком.
4) Покупая новое железо у HP по GPL еще и с расширенной гарантией я покупаю новое железо с расширенной гарантией. А вот переезжая в облако — в качестве основы я получаю б/у сервера и неизвестно какие диски в СХД (хотя в случае со своим решением вы разумеется посчитали самые дорогие для увеличения CAPEX)
Вкратце — хранить железо у себя невыгодно, это большие минусы, переезжайте к нам мы храним железо у себя и внезапно это оказывается выгодно (нам) (с)
Хорошая попытка, но нет
Ведь в облако вы перевозите только «стойку с серверами», а это далеко не вся it инфраструктура заказчика.
2)Затраты на обслуживание своей стойки у вас в расчетах дублируются. Указывайте что-то одно — либо расширенную гарантию, либо стоимость обслуживания
3) Плюс мы сразу добавляем к ОРЕХу стоимость возросших каналов между офисом и облаком.
4) Покупая новое железо у HP по GPL еще и с расширенной гарантией я покупаю новое железо с расширенной гарантией. А вот переезжая в облако — в качестве основы я получаю б/у сервера и неизвестно какие диски в СХД (хотя в случае со своим решением вы разумеется посчитали самые дорогие для увеличения CAPEX)
Вкратце — хранить железо у себя невыгодно, это большие минусы, переезжайте к нам мы храним железо у себя и внезапно это оказывается выгодно (нам) (с)
Хорошая попытка, но нет
Стоимость спецификации клиенту тоже Техносерв считал? Можно только посочуствовать доверию клиента интегратору, кем бы он ни был.
На месте CFO я бы сильно наказал закуперов за 25% на такой сумме контракта (HP судя по статье не первый раз покупают).
И да "и ящик водки обратно". В смысле свои железки.
Простите, может что-то не понял.
Собственнное ИТ-решение 721 тыс/мес
Облачная услуга 606 тыс/мес
О чём вторая половина статьи? Ведь облачное выгоднее.
Собственнное ИТ-решение 721 тыс/мес
Облачная услуга 606 тыс/мес
О чём вторая половина статьи? Ведь облачное выгоднее.
Я все правильно понял? В статье железо посчитали на 17ТБ а облако на 12ТБ?
На мой взгляд, на 5 серверов и 17 ТБ, в ряде случаев хватит и MSA2xxx, а если в расчетах имеется в виду all flash массив — то это надо указывать т.к. сильно влияет на цену как железа так и облака.
На мой взгляд, на 5 серверов и 17 ТБ, в ряде случаев хватит и MSA2xxx, а если в расчетах имеется в виду all flash массив — то это надо указывать т.к. сильно влияет на цену как железа так и облака.
Ну то что расчет сделан для болванов все уже поняли, я хочу добавить пару слов:
1. Экономика в РФ везде по разному не стабильная, что будет если сейчас денег выделили а на следующий год нет или мало/меньше? Отдельный вопрос кстати фиксации цены на облако в РФ, я имею в виду валюта и условия изменения (повышения :) ) цен.
2. Учитывая п1 и то, что 2006-7 год давно позади и денег не много, я не думаю что сервера выкидываются через 5 лет эксплуатации если с ними все порядке следовательно считать 5 лет не совсем корректно. Мне кажется что в РФ скорее дефицит железа чем избыток, следовательно для старого сервака задачу найдут.
3. Непрозрачность в реалиях РФ просто шкалящая: кто и когда имеет доступ к оборудованию (включая силовые структуры)? Какая цепочка услуг-посредников-субподрядчиков контракта? Какое оборудование используется в облаке и есть ли на него контракты сервисные?
4. Вообще у меня есть сомнения относительно качества услуг наших Мега облаков, в Амазоне круто что если мне нужно к концу квартала какую то специфичную считалку для репортов которая будет работать с особенными пиками нагрузки — я ее закажу и заплачу ровно до копейки за то сколько минут она работала. Насколько API, например техносерва, такую оркестрацию предоставляет, а тарифы гибкость — я не знаю. И также касаемо надежности/DR — хочу иметь гео кластер — галку жмакнул и получил, для энтерпрайза это важно.
Вообще расчет сделан по лекалам США/Европа НО у них на стороне заказчиков: стабильность валюты, стабильность-прогнозируемость экономики, очень высокая цены персонала; а на другой стороне Азур, AWS и Google которые во первых режут косты в глобальных масштабах, а во вторых не покупают стораджи 3par для своих облаков.
Вот посмотрите всерьез, кто из ентерпрайзов в РФ планирует реальный бюджет на 5 лет? Государство живет в однолетнем бюджете.
1. Экономика в РФ везде по разному не стабильная, что будет если сейчас денег выделили а на следующий год нет или мало/меньше? Отдельный вопрос кстати фиксации цены на облако в РФ, я имею в виду валюта и условия изменения (повышения :) ) цен.
2. Учитывая п1 и то, что 2006-7 год давно позади и денег не много, я не думаю что сервера выкидываются через 5 лет эксплуатации если с ними все порядке следовательно считать 5 лет не совсем корректно. Мне кажется что в РФ скорее дефицит железа чем избыток, следовательно для старого сервака задачу найдут.
3. Непрозрачность в реалиях РФ просто шкалящая: кто и когда имеет доступ к оборудованию (включая силовые структуры)? Какая цепочка услуг-посредников-субподрядчиков контракта? Какое оборудование используется в облаке и есть ли на него контракты сервисные?
4. Вообще у меня есть сомнения относительно качества услуг наших Мега облаков, в Амазоне круто что если мне нужно к концу квартала какую то специфичную считалку для репортов которая будет работать с особенными пиками нагрузки — я ее закажу и заплачу ровно до копейки за то сколько минут она работала. Насколько API, например техносерва, такую оркестрацию предоставляет, а тарифы гибкость — я не знаю. И также касаемо надежности/DR — хочу иметь гео кластер — галку жмакнул и получил, для энтерпрайза это важно.
Вообще расчет сделан по лекалам США/Европа НО у них на стороне заказчиков: стабильность валюты, стабильность-прогнозируемость экономики, очень высокая цены персонала; а на другой стороне Азур, AWS и Google которые во первых режут косты в глобальных масштабах, а во вторых не покупают стораджи 3par для своих облаков.
Вот посмотрите всерьез, кто из ентерпрайзов в РФ планирует реальный бюджет на 5 лет? Государство живет в однолетнем бюджете.
про пункт:
>В облаке можно арендовать лицензии Microsoft (или программные услуги) и не закупать лицензии на годы вперёд, а оплачивать по фактическому использованию ежемесячно.
В последние года, ~ с 2014 года, почти все корпораты сидят на подписках на ПО и ОС на 3 года с возможностью проводить перерасчёт в большую сторону когда нужно. И прекрасно его размещают на своих железках.
>В облаке можно арендовать лицензии Microsoft (или программные услуги) и не закупать лицензии на годы вперёд, а оплачивать по фактическому использованию ежемесячно.
В последние года, ~ с 2014 года, почти все корпораты сидят на подписках на ПО и ОС на 3 года с возможностью проводить перерасчёт в большую сторону когда нужно. И прекрасно его размещают на своих железках.
— Не увидел в расчетах стоимости толстенного канала связи до этого прекрасного облака;
— 17Гб СХД — это слезы.
Долго писать не хочется… если нужно действительно объемное хранилище — облако в пролете, там хорошие цены только при небольших объемах. Канал связи — еще одна точка отказа, если постоянно льются данные изнутри компании и обратно — то облако в пролете. Я уже не говорю про кучу вопросов по безопасности, которая может стоить сильно дороже всей этой груды железа и ФОТ одного админа (который к слову может параллельно заниматься многими другими полезными для бизнеса вещами).
Есть еще куча «но», почему большие компании нередко предпочитают свои ЦОДы и даже отказываются от облаков. А вот для малого бизнеса — таки да, это выгодно.
— 17Гб СХД — это слезы.
Долго писать не хочется… если нужно действительно объемное хранилище — облако в пролете, там хорошие цены только при небольших объемах. Канал связи — еще одна точка отказа, если постоянно льются данные изнутри компании и обратно — то облако в пролете. Я уже не говорю про кучу вопросов по безопасности, которая может стоить сильно дороже всей этой груды железа и ФОТ одного админа (который к слову может параллельно заниматься многими другими полезными для бизнеса вещами).
Есть еще куча «но», почему большие компании нередко предпочитают свои ЦОДы и даже отказываются от облаков. А вот для малого бизнеса — таки да, это выгодно.
Извините, а ФОТ ИТ персонала 104 тыс в месяц? А что это за персонал посчитан? ( Выше уже видел, что тоже не понимают данного вопроса народ.
Облаком ни кто не будет управлять?
Разовый платеж, как то странно что его нет, а кто тогда будет настраиваться вся инфраструктура — сеть, сервера и тд?
Виртуализация VMware: vCPU — 325; RAM — 1 526 Гб, HDD — 12 250 Гб. — это один сервер, не думаю, это целая инфраструктура и ее нужно будет спланировать, настроить, что-то туда перенести из существующей инфраструктуры, при этом учесть простои и тд.
Облаком ни кто не будет управлять?
Разовый платеж, как то странно что его нет, а кто тогда будет настраиваться вся инфраструктура — сеть, сервера и тд?
Виртуализация VMware: vCPU — 325; RAM — 1 526 Гб, HDD — 12 250 Гб. — это один сервер, не думаю, это целая инфраструктура и ее нужно будет спланировать, настроить, что-то туда перенести из существующей инфраструктуры, при этом учесть простои и тд.
ФОТ ИТ персонала 104 тыс в месяц – это экспертная оценка затрат только на поддержку проекта, переносимого в облако. Фактически это 1 системный администратор, который поддерживает несколько проектов клиента, включая переносимый в облако, и обладающий навыками работы в vCloud Director.
Расходы на управление облаком со стороны сервис провайдера заложены в тарифы на облако.
Разового платежа нет, потому что инфраструктура для клиента разворачивается в публичном облаке, облако уже сконфигурировано и настроено таким образом, что дополнительно не требуется делать большого количества настроек под каждого клиента.
Своими виртуальными ресурсами в облаке клиент управляет самостоятельно: конфигурирование виртуальных машин и сетей, настройка IPsecVPN и т.д. Затраты со стороны клиента на проектирование инфраструктуры, настройку, планирование миграции и саму миграцию не включены в кейс, потому что они есть у клиента в обоих случаях.
С ФОТом все равно не ясно, почему выделили не понятного сотрудника со знанием каких решений? Если компания не будет брать облако, а решит купить железо и поставить у себя в серверной? Это сотрудник, как Вы выше написали ( сотрудник ЦОДА?) раз он поддерживает нескольких клиентов в облаках. Тогда почему расходы ФОТ стоят под собственным решением? ( Как минимум необходимы специалисты по СХД и специалисты по Vmware )
А куда делись 37 миллионов? Почему только Opex сокращен? Вместо там 700тыс в месяц, компания получает все хотелки за 600 тыс в месяц, при этом не тратит 37 лимонов?
А куда делись 37 миллионов? Почему только Opex сокращен? Вместо там 700тыс в месяц, компания получает все хотелки за 600 тыс в месяц, при этом не тратит 37 лимонов?
Под собственным решением понимается in-hous решение, которое клиент закупает, полностью им владеет и самостоятельно управляет. Решение размещается в серверной клиента или его ЦОДе. ФОТ в этой колонке указан на собственный ИТ-персонал клиента. В данном случае клиент посчитал, что у него есть сотрудник, который переиспользуется на несколько проектов, знакомый с администрированием VMware. Как раз в этом случае и есть риск, что этот один сотрудник в какой-то момент времени может оказаться некомпетентным в каком-либо вопросе или сильно перегруженным. Может потребоваться его дополнительное обучение или привлечение дополнительного персонала, что влечет за собой дополнительные расходы для компании.
Единоразовых расходов 38 575 млн. руб. в случае использования облачной услуги у клиента нет, потому что он приобретает ИТ-инфраструктуру на облачной платформе и ежемесячно платит только за использование этой инфраструктуры. В этом случае ему не требуется закупать оборудование на несколько лет вперед.
Вы забыли предложить среднее решение: пойти в приличный ДЦ, арендовать там голое железо под нужны проекта, договориться, что срок аренды будет таким вот — и цифра аренды в месяц окажется, во-первых, меньшей, чем облако (причем надежность и ЗИП будет за счет ДЦ), а, во-вторых, аренда пойдет в OPEX, а не в CAPEX.
Да, к этому не забудет ФОТ своих спецов добавить (это мы оплачиваем просто вынос стойки в ДЦ и аренду железа) и канал до ДЦ, но это более понятно для всех — и для админов, и для бизнеса.
Да, к этому не забудет ФОТ своих спецов добавить (это мы оплачиваем просто вынос стойки в ДЦ и аренду железа) и канал до ДЦ, но это более понятно для всех — и для админов, и для бизнеса.
Цены на железо из расчёта выглядят какими-то просто аэрокосмическими. 17,5 миллионов за СХД ёмкостью 17ТБ?
Скажем, к этой СХД подходят 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 с лишним миллионов?
Скажем, к этой СХД подходят 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 с лишним миллионов?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Закупка железа против облака: как правильно считать