В апреле 2017 года исполнится год, как запущен в коммерческую эксплуатацию проект mClouds.ru, основная цель которого — предоставление ресурсов хранения и вычисления для b2b-клиентов. За прошедшее время нами был получен интересный опыт, от выбора технических решений до решения факапов, которым мы хотим поделиться с вами. История первая — о муках выбора ЦОД в самой большой стране мира. Собственно, от величины проблемы и начались.
Проект запущен системным интегратором «Мастер», базирующемся в г. Тюмень, как у нас говорят — Лучшем городе земли. Идея запуска mСlouds.ru состояла изначально не в том, чтобы выходить на открытый рынок облачного хостинга, а в том, чтобы предоставить своим b2b-клиентам вычислительные ресурсы для песочниц и резервных нужд, как например генерация отчётов, удалённый репозиторий для резервных копий, внешний мониторинг, не основные базы данных. Также решение покрывает потребности небольших компаний SMB сектора в серверах, используемых для 1С: Предприятия. Если учесть, что с ростом курса доллара покупать собственные серверы, не говоря уж о обеспечении их ИБП, охлаждением и прочей инфраструктурой, стало отнимать много финансовых ресурсов. Поэтому внутри нашей компании было принято решение — развить собственное облачное направление, благо технический бэкграунд наших инженеров это позволял и позволяет.
Нами был поставлен срок выхода в продуктивную среду на первые числа апреля и в течение трёх месяцев мы обкатывали программные и аппаратные возможности на базе платформы VMware vSphere. Кроме того, нам удалось адаптировать для облачной инфраструктуры многие Enterprise-решения, и это интересный опыт, которым мы хотим поделиться.
Гравировка при входе в центр компетенций — наш персональный ЦК
Наш проект начал работать в Центре Компетенций (далее по тексту ЦК) на базе нашей компании, поэтому вопроса о выборе площадки не было. Мощности охлаждения и ИБП вполне хватало для обеспечения корректной работы подсистемы охлаждения и энергопитания. Однако ближе к намеченной дате выхода на рынок обозначилась проблема, где проект должен будет жить? Учитывая, что мы находимся не в Москве или Санкт-Петербурге, где с этим нет никаких проблем (все-таки там сосредоточено большинство всех коммерческих центров обработки данных в стране), то для Тюмени это вовсе не тривиальный вопрос.
Итак, в Тюмени есть всё что угодно, кроме грамотных коммерческих ЦОД, а с таким термином как TIER 3 здесь знакомы не все, включая те площадки, которые мы посетили для ознакомления. Есть корпоративные серверные помещения, несколько государственных ЦОД, площадки телеком-провайдеров, но как таковых коммерческих ЦОД нет, не говоря уж о какой-либо их сертификации. С каналами интернет тоже не все благополучно, например, подключение с пропускной способностью в 1Гбит/сек стоит совсем дорого. Если сказать о том, что канал должен иметь перспективу роста до 10 Гбит/сек, то глаза и вовсе округлялись, на лице или по телефону считывалось, что ребята первый раз услышали запросы на такие скорости в нашем регионе. Так что мы начали смотреть на ЦОДы в РФ.
Австралия совсем рядом. Изображение: whatarethe7continents.com
Екатеринбург — в данном городе есть ЦОД операторов связи, например Мегафон и Ростелеком. Но в процессе общения мы поняли, что предоставление и уровень сервиса, требуемый для облачного провайдера, это не к ним, так как они сами акцентируют внимание больше на предоставление вычислительных ресурсов, нежели на предоставление услуги по размещению оборудования. В итоге, адекватный ценник мы так и не получили, продолжаем изучение.
Дата-центр ГАУ «ИТ-ПАРК», республика Татарстан
Казань — здесь уже всё получше, есть ИТ-парк, Иннополис, видно что в ИТ тут понимают, интересуются и любят это направление. Достаточно профессионально подходят, но опять уже учитывая наше расположение — логистически нам очень уж неудобно до Казани добираться. Поэтому тонких моментов, как инженерку, SLA и каналы связи не рассматривали.
В сухом остатке — Москва и Санкт-Петербург. Фото: periskop.livejournal.com
Начали обзор рынка с Санкт-Петербурга. Первый дата-центр (далее ДЦ), на который обратили внимание оказался ЦОД SDN. Достойный уровень инженерных систем с довольно чётким описанием, интересные соседи, например ВКонтакте, адекватная цена, уровень общения и готовность отвечать на все наши вопросы. Далее были рассмотрены услуги colocation от Selectel, Fiord и других ДЦ. Мы почти приняли для себя решение размещать mClouds.ru именно в питерском SDN. Однако на весы опять встала логистика, хоть в SDN есть услуга удалённых рук, тем не менее в случае какой-либо нештатной ситуации (да и штатной тоже) мы не смогли бы оперативно десантироваться в Питер, учитывая что мы физически находимся в Тюмени и, увы, в Санкт-Петербург до нас всего один рейс в день, — а это очень высокие риски по сроку реагирования. Однако для тех, у кого нет сложностей с логистикой до Питера, SDN однозначно один из лучших среди рассмотренных вариантов, как нам кажется.
Рынок коммерческих ЦОД Москвы, конечно, самый крупный. Тут есть из чего выбрать. Сами ЦОДы мы разделили на несколько категорий:
Рассмотрим первую категорию. Основные потребители услуг — заказчики интеграторов, им же и основной приоритет. На наш взгляд, ориентация явно не на небольшие проекты. Примеры — ЦОД «Компрессор» компании КРОК, ЦОД «Траст-Инфо» от Ай-теко.
Вторая категория. Ассоциации — красиво, круто и… дорого. Из первичного отбора мы выделили три компании: DataSpace, DataPro и Dataline. Посмотрели, облизнулись и пошли дальше. В данные ДЦ надо приходить когда проект уже подрос, ну что же, ушли расти.
Третья категория — это ЦОД телеком-операторов. Достаточно низкая гибкость за счёт постоянных и очень долгих согласований, долгие ответы менеджеров, отсутствие доступа к оборудованию в ночное время и порядок цен, сопоставимый с сертифицированными ДЦ.
Четвертая категория. К слову сказать, из этого категории мы и выбрали наш будущий дом для проекта. Выбрали ЦОД, который позиционируется как сеть клубных дата-центров. Понравились быстротой реакции, готовностью все показать и рассказать, связностью с другими площадками, готовностью получить наше оборудование из транспортной компании и своими силами смонтировать его в стойке, что для нас означало значительную экономию на командировках инженеров. Инфраструктура ЦОДа подходила под наши требования.
Забегая вперед скажу, что проработали мы в выбранном ЦОД до конца 2016 года. В течении года был один простой летом на 2 часа 30 минут из-за сбоя в системе кондиционирования, и сбой сетевого оборудования ЦОДа, в результате мы потеряли каналы связи до внешнего мира на несколько часов. К сожалению, компетенций сотрудников ЦОДа не хватило для быстрого устранения сбоя и как впоследствии мы узнали, на площадке не было резервного оборудования. Сделали выводы и устранили возможное повторение такой ситуации в будущем. Всем клиентам были вынуждены компенсировать месячную абонентскую плату, хоть формально и оставались в рамках SLA. А ведь ЦОД это все-таки основа, фундамент работоспособности оборудования. Это запишем в минусы этой категории ЦОДов.
Пятую категорию мы серьезно не рассматривали. Тут собственные ЦОДы хостинг-провайдеров, которые переделаны из каких-либо помещений и с тем или иным успехом эксплуатируются. Инвестиции в собственные площадки достойны уважения, но мы считаем, что купить профессиональную услугу и сервис будет более функционально и надёжно. Но экономика, конечно, может пострадать, что отразится на конечной стоимости услуги.
Как итог мы с нового 2017 года работаем в сертифицированном ЦОД NORD4 по программе TIER 3 от Uptime Institute, компании Dataline. Очень адекватный сервис, высокая гибкость и, самое главное, — высокая надежность. Детально прописанный договор и подробный SLA по работоспособности и реакции. На Хабре уже были обзоры этого ЦОД и подробное описание инфраструктуры.
Вот так мы кратко разобрали наш опыт выбора ЦОДа для облачного проекта mClouds.ru. Надеемся он будет полезен тем, кто выбирает ЦОД для своих проектов или сервисов.
В следующих статьях мы опишем уже технические особенности функционирования непосредственно нашей инфраструктуры и применяемые решения.
Проект запущен системным интегратором «Мастер», базирующемся в г. Тюмень, как у нас говорят — Лучшем городе земли. Идея запуска mСlouds.ru состояла изначально не в том, чтобы выходить на открытый рынок облачного хостинга, а в том, чтобы предоставить своим b2b-клиентам вычислительные ресурсы для песочниц и резервных нужд, как например генерация отчётов, удалённый репозиторий для резервных копий, внешний мониторинг, не основные базы данных. Также решение покрывает потребности небольших компаний SMB сектора в серверах, используемых для 1С: Предприятия. Если учесть, что с ростом курса доллара покупать собственные серверы, не говоря уж о обеспечении их ИБП, охлаждением и прочей инфраструктурой, стало отнимать много финансовых ресурсов. Поэтому внутри нашей компании было принято решение — развить собственное облачное направление, благо технический бэкграунд наших инженеров это позволял и позволяет.
Нами был поставлен срок выхода в продуктивную среду на первые числа апреля и в течение трёх месяцев мы обкатывали программные и аппаратные возможности на базе платформы VMware vSphere. Кроме того, нам удалось адаптировать для облачной инфраструктуры многие Enterprise-решения, и это интересный опыт, которым мы хотим поделиться.
Выбор площадки проекта
Гравировка при входе в центр компетенций — наш персональный ЦК
Наш проект начал работать в Центре Компетенций (далее по тексту ЦК) на базе нашей компании, поэтому вопроса о выборе площадки не было. Мощности охлаждения и ИБП вполне хватало для обеспечения корректной работы подсистемы охлаждения и энергопитания. Однако ближе к намеченной дате выхода на рынок обозначилась проблема, где проект должен будет жить? Учитывая, что мы находимся не в Москве или Санкт-Петербурге, где с этим нет никаких проблем (все-таки там сосредоточено большинство всех коммерческих центров обработки данных в стране), то для Тюмени это вовсе не тривиальный вопрос.
Итак, в Тюмени есть всё что угодно, кроме грамотных коммерческих ЦОД, а с таким термином как TIER 3 здесь знакомы не все, включая те площадки, которые мы посетили для ознакомления. Есть корпоративные серверные помещения, несколько государственных ЦОД, площадки телеком-провайдеров, но как таковых коммерческих ЦОД нет, не говоря уж о какой-либо их сертификации. С каналами интернет тоже не все благополучно, например, подключение с пропускной способностью в 1Гбит/сек стоит совсем дорого. Если сказать о том, что канал должен иметь перспективу роста до 10 Гбит/сек, то глаза и вовсе округлялись, на лице или по телефону считывалось, что ребята первый раз услышали запросы на такие скорости в нашем регионе. Так что мы начали смотреть на ЦОДы в РФ.
Что есть вблизи?
Австралия совсем рядом. Изображение: whatarethe7continents.com
Екатеринбург — в данном городе есть ЦОД операторов связи, например Мегафон и Ростелеком. Но в процессе общения мы поняли, что предоставление и уровень сервиса, требуемый для облачного провайдера, это не к ним, так как они сами акцентируют внимание больше на предоставление вычислительных ресурсов, нежели на предоставление услуги по размещению оборудования. В итоге, адекватный ценник мы так и не получили, продолжаем изучение.
Дата-центр ГАУ «ИТ-ПАРК», республика Татарстан
Казань — здесь уже всё получше, есть ИТ-парк, Иннополис, видно что в ИТ тут понимают, интересуются и любят это направление. Достаточно профессионально подходят, но опять уже учитывая наше расположение — логистически нам очень уж неудобно до Казани добираться. Поэтому тонких моментов, как инженерку, SLA и каналы связи не рассматривали.
В сухом остатке — Москва и Санкт-Петербург. Фото: periskop.livejournal.com
Начали обзор рынка с Санкт-Петербурга. Первый дата-центр (далее ДЦ), на который обратили внимание оказался ЦОД SDN. Достойный уровень инженерных систем с довольно чётким описанием, интересные соседи, например ВКонтакте, адекватная цена, уровень общения и готовность отвечать на все наши вопросы. Далее были рассмотрены услуги colocation от Selectel, Fiord и других ДЦ. Мы почти приняли для себя решение размещать mClouds.ru именно в питерском SDN. Однако на весы опять встала логистика, хоть в SDN есть услуга удалённых рук, тем не менее в случае какой-либо нештатной ситуации (да и штатной тоже) мы не смогли бы оперативно десантироваться в Питер, учитывая что мы физически находимся в Тюмени и, увы, в Санкт-Петербург до нас всего один рейс в день, — а это очень высокие риски по сроку реагирования. Однако для тех, у кого нет сложностей с логистикой до Питера, SDN однозначно один из лучших среди рассмотренных вариантов, как нам кажется.
Рынок коммерческих ЦОД Москвы, конечно, самый крупный. Тут есть из чего выбрать. Сами ЦОДы мы разделили на несколько категорий:
- ЦОД крупных интеграторов
- коммерческие ЦОД, сертифицированные по программе Uptime Institute
- ЦОД телеком-операторов
- небольшие и самостоятельные коммерческие ЦОД, заявляющие соответствие уровню Tier 3
- площадки различных хостеров, от самостоятельных до выделенных зон в крупных коммерческих ЦОД
Рассмотрим первую категорию. Основные потребители услуг — заказчики интеграторов, им же и основной приоритет. На наш взгляд, ориентация явно не на небольшие проекты. Примеры — ЦОД «Компрессор» компании КРОК, ЦОД «Траст-Инфо» от Ай-теко.
Вторая категория. Ассоциации — красиво, круто и… дорого. Из первичного отбора мы выделили три компании: DataSpace, DataPro и Dataline. Посмотрели, облизнулись и пошли дальше. В данные ДЦ надо приходить когда проект уже подрос, ну что же, ушли расти.
Третья категория — это ЦОД телеком-операторов. Достаточно низкая гибкость за счёт постоянных и очень долгих согласований, долгие ответы менеджеров, отсутствие доступа к оборудованию в ночное время и порядок цен, сопоставимый с сертифицированными ДЦ.
Четвертая категория. К слову сказать, из этого категории мы и выбрали наш будущий дом для проекта. Выбрали ЦОД, который позиционируется как сеть клубных дата-центров. Понравились быстротой реакции, готовностью все показать и рассказать, связностью с другими площадками, готовностью получить наше оборудование из транспортной компании и своими силами смонтировать его в стойке, что для нас означало значительную экономию на командировках инженеров. Инфраструктура ЦОДа подходила под наши требования.
Забегая вперед скажу, что проработали мы в выбранном ЦОД до конца 2016 года. В течении года был один простой летом на 2 часа 30 минут из-за сбоя в системе кондиционирования, и сбой сетевого оборудования ЦОДа, в результате мы потеряли каналы связи до внешнего мира на несколько часов. К сожалению, компетенций сотрудников ЦОДа не хватило для быстрого устранения сбоя и как впоследствии мы узнали, на площадке не было резервного оборудования. Сделали выводы и устранили возможное повторение такой ситуации в будущем. Всем клиентам были вынуждены компенсировать месячную абонентскую плату, хоть формально и оставались в рамках SLA. А ведь ЦОД это все-таки основа, фундамент работоспособности оборудования. Это запишем в минусы этой категории ЦОДов.
Пятую категорию мы серьезно не рассматривали. Тут собственные ЦОДы хостинг-провайдеров, которые переделаны из каких-либо помещений и с тем или иным успехом эксплуатируются. Инвестиции в собственные площадки достойны уважения, но мы считаем, что купить профессиональную услугу и сервис будет более функционально и надёжно. Но экономика, конечно, может пострадать, что отразится на конечной стоимости услуги.
Как итог мы с нового 2017 года работаем в сертифицированном ЦОД NORD4 по программе TIER 3 от Uptime Institute, компании Dataline. Очень адекватный сервис, высокая гибкость и, самое главное, — высокая надежность. Детально прописанный договор и подробный SLA по работоспособности и реакции. На Хабре уже были обзоры этого ЦОД и подробное описание инфраструктуры.
Вот так мы кратко разобрали наш опыт выбора ЦОДа для облачного проекта mClouds.ru. Надеемся он будет полезен тем, кто выбирает ЦОД для своих проектов или сервисов.
В следующих статьях мы опишем уже технические особенности функционирования непосредственно нашей инфраструктуры и применяемые решения.