Рейтинг
0.00

Miran Дата-центры

3 читателя, 46 топиков

Хватит думать, что SLA вас спасет. Оно нужно, чтобы успокоить и создать ложное чувство безопасности



SLA, оно же «service-level agreement» —соглашение-гарантия между заказчиком и поставщиком услуг о том, что получит клиент в плане обслуживания. Также в нем оговариваются компенсации в случае простоев по вине поставщика и так далее. По сути SLA — это верительная грамота, с помощью которой дата-центр или хостинг-провайдер убеждает потенциального клиента в том, что он будет всячески обласкан и вообще. Вопрос в том, что в SLA можно написать все что угодно, да и события, прописанные в этом документе, наступают не слишком часто. SLA — это далеко не ориентир в подборе дата-центра и надеяться на него уж точно не стоит.

Все мы привыкли подписывать какие-то договоры, которые возлагают определенные обязательства. Не исключением является и SLA — обычно самый оторванный от реалий документ, который можно вообразить. Более бесполезен, наверное, только NDA в юрисдикциях, где понятия «коммерческой тайны» толком не существует. А вся проблема в том, что SLA никак не помогает клиенту в правильном выборе поставщика, а только пускает пыль в глаза.

Что чаще всего пишут в публичной версии SLA хостеры, которую показывают публике? Ну, первой строкой идет такой термин, как «надежность» хостера — это обычно цифры от 98 до 99,999%. По сути, эти цифры — лишь красивая выдумка маркетологов. Когда-то, когда хостинг был молодым и дорогим, а облака только снились специалистам (как и широкополосный доступ для всех и каждого), показатель аптайма хостинга был крайне и крайне важен. Сейчас же, когда все поставщики используют плюс-минус одно и тоже оборудование, сидят на один и тех же магистральных сетях и предлагают одни и те же пакеты услуг, показатель аптайма абсолютно непоказателен.

Бывает ли вообще «правильный» SLA
Конечно существуют и идеальные версии SLA, но все они являются нетиповыми документами и прописываются и заключаются между клиентом и поставщиком в ручном режиме. При этом именно этот тип SLA чаще всего касается каких-то подрядных работ, нежели услуг.

Что должно быть в хорошем SLA? Если дать TLDR, то хороший SLA — это регулирующий отношения двух субъектов документ, который дает одной из сторон (заказчику) максимум контроля над процессом. То есть, как это работает в реальном мире: есть документ, который описывает глобальные процессы взаимодействия и регулирует взаимоотношения сторон. Он устанавливает границы, правила и сам по себе становится рычагом воздействия, которым могут пользоваться обе стороны в полной мере. Так, благодаря правильному SLA заказчик просто может заставить исполнителя работать так, как договаривались, а исполнителю — помогает отбиваться от необоснованных договором «хотелок» слишком уж активного клиента. Выглядит так: «У нас в SLA написано так и так, идите отсюда, мы все делаем как оговорено».

То есть «правильный SLA» = «адекватный договор на оказание услуг» и дает контроль над ситуацией. А возможно это только при работе «на равных».

То, что пишут на сайте и то, что ждет в реальности — разные вещи
Вообще, все, что мы будем обсуждать дальше — типичные маркетинговые уловки и проверка на внимательность.

Если взять популярных отечественных хостеров, то одно предложение краше другого: поддержка 25/8, аптайм серверов 99,9999999% времени, куча своих дата-центров минимум по России. Запомните, пожалуйста, момент про дата-центры, мы к нему вернемся чуть позже. А пока поговорим про идеальную статистику отказоустойчивости и с чем сталкивается человек, когда его сервер все же попадает в «0,0000001% падений».

При показателях от 98% и выше, любое падение — событие на грани статистической погрешности. Рабочее оборудование и коннект либо есть, либо их нет. Вы можете годами пользоваться хостером с показателем «надежности» в 50% (согласно его же SLA) без единой проблемы или «падать» раз в месяц на пару дней у ребят, где заявлено 99,99%.

Когда момент падения все же настает (а падают, напоминаем, когда-нибудь все), то тут клиент сталкивается с внутренней корпоративной машиной под названием «поддержка», а на свет достается договор на оказание услуг и SLA. Что это значит:
  • скорее всего, за первые четыре часа простоя вы вообще ничего предъявить не сможете, хотя некоторые хостеры начинают пересчет тарифа (выплату компенсации) с момента падения.
  • Если сервер недоступен большее время, возможно, вы сможете подать требование на пересчет тарифа.
  • И это при условии, что проблема возникла по вине поставщика.
  • Если ваша проблема возникла по причине третьей стороны (на магистрали), то вроде как «никто не виноват» и когда решится проблема — вопрос вашей удачливости.

При этом важно понимать, что вы никогда не получаете доступ к инженерной команде, чаще всего вас останавливает первая линия поддержки, которая ведет с вами переписку, пока настоящие инженеры пытаются исправить ситуацию. Знакомый сценарий?

Тут многие надеются на SLA, которое, вроде как, должно защищать вас от подобных ситуаций. Но, по факту, компании редко когда выходят за границы своего собственного документа либо умеют повернуть ситуацию так, чтобы минимизировать собственные расходы. Первоочередная задача SLA — усыпить бдительность и убедить, что даже в случае непредвиденной ситуации «все будет хорошо». Вторая задача SLA — проговорить основные критические моменты и дать поставщику услуг пространство для маневра, то есть возможность списать сбой на что-нибудь, за что поставщик «не несет ответственности».

При этом крупным клиентам, по факту, вообще плевать на компенсации в рамках SLA. «Компенсация по SLA» — это возврат денег в рамках тарифа пропорционально простою оборудования, которая никогда не покроет даже 1% потенциальных денежных и репутационных потерь. В этом случае клиенту намного важнее, чтобы неполадки были устранены в кратчайшие сроки, нежели какой-то там «пересчет тарифа».

«Множество дата-центров по всему миру» — повод для беспокойства
Ситуацию с большим количеством дата-центров у поставщика услуг мы вынесли в отдельную категорию, потому что кроме очевидных вышеописанных проблем с коммуникацией всплывают проблемы и неочевидные. Например, ваш поставщик услуг не имеет доступа к «своим» дата-центрам.

В нашей прошлой статье мы писали о видах партнерских программ и упомянули модель «White Label», суть которой заключается в перепродаже чужих мощностей под своей вывеской. Подавляющее большинство современных хостеров, которые заявляют о наличии «своих дата-центров» во множестве регионов, являются перекупщиками по модели White Label. То есть, физически они не имеют никакого отношения к условному дата-центру в Швейцарии, Германии или Нидерландах.

Тут возникают крайне интересные коллизии. Ваше SLA с поставщиком услуг все еще работает и является действующим, но как-то кардинально повлиять на ситуацию в случае аварии поставщик не способен. Он сам находится в зависимом положении от своего собственного поставщика — дата-центра, у которого и были куплены стойки-мощности для перепродажи.

Таким образом, если вам важны не только красивые формулировки в договоре и SLA о надежности и сервисе, но и способность поставщика услуг оперативно решать проблемы — стоит напрямую работать с владельцем мощностей. На самом деле, это подразумевает прямое взаимодействие непосредственно с дата-центром.

Почему мы не рассматриваем варианты, когда множество ДЦ на самом деле может принадлежать одной компании? Ну, таких компаний очень и очень немного. Один, два, три небольших дата-центра или один крупный — это реально. Но десяток ДЦ, половина из которых в РФ, а вторая на территории Европы — практически невозможно. А это значит, что компаний-перекупщиков намного больше, чем можно себе представить. Вот простой пример:


Оцените количество дата-центров сервиса Google Cloud. В Европе их всего шесть. В Лондоне, Амстердаме, Брюсселе, Хельсинки, Франкфурте и Цюрихе. То есть на всех основных магистральных точках. Потому что дата-центр — это дорого, сложно и очень большой проект. А теперь вспомните хостинговые компании откуда-то из Москвы с «десятком дата-центров по всей России и Европе».

Нет, конечно, хороших поставщиков, имеющих партнеров по программе White Label, достаточно, и они оказывают услуги по высшему разряду. Они дают возможность арендовать мощности в ЕС и РФ одновременно через одно и то же окно браузера, принимают оплату в рублях, а не в валюте, и так далее. Но при наступлении случаев, описанных в SLA, они становятся точно такими же заложниками ситуации, как и вы.

Это еще раз напоминает нам, что SLA бесполезен, если вы не имеете понятия о структуре организации и мощностей поставщика.

Что в итоге
Падение серверов — это всегда неприятное событие и случиться оно может с кем угодно и где угодно. Вопрос в том, какую степень контроля за ситуацией вы хотите. Сейчас на рынке не слишком много прямых поставщиков мощностей, а если говорить о крупных игроках, то им принадлежит, условно, только один ДЦ где-нибудь в Москве из десятка по всей Европе, к которым вы можете получить доступ.

Тут каждый клиент должен сам для себя решать: я выбираю комфорт прямо сейчас или трачу время и силы на поиск дата-центра в приемлемой точке России или Европы, где смогу разместить свое оборудование или купить мощности. В первом случае подойдут стандартные решения, которые сейчас есть на рынке. Во втором — придется попотеть.

В первую очередь нужно выявить, является ли продавец услуг непосредственным владельцем мощностей/дата-центра. Очень многие перекупщики по модели White Label изо всех сил маскируют свой статус и в этом случае надо смотреть на какие-то косвенные признаки. Например, если «их европейские ДЦ» имеют какие-то специфические названия и логотипы, отличающиеся от названия компании-поставщика. Или если где-то мелькает слово «партнеры». Партнеры = White Label в 95% случаев.

Далее необходимо ознакомиться с самой структурой компании, а лучше вживую посмотреть на оборудование. Среди дата-центров не нова практика экскурсий или как минимум экскурсионных статей на собственном сайте или в блоге (мы такие писали, раз и два), где они рассказывают о своем дата-центре с фотографиями и подробными описаниями.

Со многими дата-центрами можно договориться о личном визите в офис и мини-экскурсии в сам ДЦ. Там можно оценить степень порядка, возможно, удастся пообщаться с кем-нибудь из инженеров. Понятно, что никто не будет устраивать вам экскурс на производство, если вам нужен один сервер за 300 RUB/месяц, но если вам требуются серьезные мощности, то отдел продаж вполне может пойти вам на встречу. Мы, например, такие экскурсии проводим.

В любом случае следует руководствоваться здравым смыслом и потребностями бизнеса. Например, при необходимости распределенной инфраструктуры (часть серверов в РФ, вторая — в ЕС), проще и выгоднее будет воспользоваться услугами хостеров, имеющих партнерские отношения с европейскими ДЦ по модели White Label. Если же вся ваша инфраструктура будет сконцентрирована в одной точке, то есть в одном дата-центре, то стоит уделить вопросу поиска поставщика некоторое время.

Потому что типовое SLA вам, скорее всего, не поможет. А вот работа с собственником мощностей, а не перекупщиком — значительно ускорит решение возможных проблем.



https://miran.ru

О партнерских программах хостинговых компаний



Сегодня мы бы хотели проговорить основные плюсы и минусы партнерских программ хостинг-провайдеров средних размеров. Актуально это, потому что все больше и больше компаний отказываются от собственной монолитной инфраструктуры где-то в подвале офиса и предпочитают платить хостеру, вместо того, чтобы самим возиться с железом и держать под это дело целый штат специалистов. А основная проблема партнерок хостинг-рынка в том, что тут нет единого стандарта: каждый выживает, как может и устанавливает свои правила, ограничения и размеры вознаграждений. Ну и еще мы бы хотели узнать мнение потенциальных участников этих программ.

Три типа современных партнерских программ
Человеку, не знакомому с понятием «партнерская программа хостинг-провайдера» может показаться, что речь идет о каких-то преференциях для клиентов или акциях и скидках, но на деле «партнерская программа» — это просто модель продаж услуг хостера через третьи руки. Если отбросить высокие формулировки, то все партнерки сводятся к одному простому тезису: приведи к нам клиента и получи свой гешефт с его чека.

Мы помним, что у каждого хостера свои правила и тараканы, так что условно можно выделить три основных типа партнерских программ:
  • баннерно-реферальная;
  • прямая реферальная;
  • White Label.

Все партнерские программы сводятся к тезису «приведи клиента», но в каждом случае есть свои нюансы и особенности, о которых стоит помнить, если вы планируете ввязаться в эту историю.

Баннерно-реферальная система
О механизме работы этого типа партнерских программ говорит само его название. Рекламно-реферальная модель ориентирована в основном на веб-мастеров и предлагает последним размещать информацию о хостере на своих сайтах с указанием реферальной ссылки, по которой в дальнейшем будет начисляться вознаграждение.

Плюсы этой системы в том, что она не требует от веб-мастеров каких-то особых телодвижений и позволяет пассивно искать дополнительные источники дохода с помощью администрируемых сайтов. Разместил баннер или кликабельную ссылку в подвале страницы и сиди себе, как рыбак, жди, что кто-то по этой ссылке или баннеру перейдет к хостеру и купит его мощности.

Однако в этой системе больше подводных камней, нежели выгод. Первое — возможно, веб-мастеру будет выгоднее прикрутить гугловый или яндексовый баннер вместо того, чтобы рекламировать такую узкоспециализированную услугу, как хостинг. Второе — в баннерной модели всегда существует проблема отложенных продаж, когда клиент нашел информацию с одного устройства, а совершил покупку уже по прямой ссылке или с другой рабочей станции. Современные инструменты аналитики, присвоения userID и механизм объединения сеансов конечно же позволяют снизить процент «потерь», но эти решения далеки от идеальных. Таким образом, веб-мастер рискует заниматься благотворительностью вместо того, чтобы получать хоть какую-нибудь копейку с обычного рекламного баннера на своем сайте. Кроме того, многие хостеры для работы по такой модели требуют быть их клиентами, что не всегда подходит нашему веб-мастеру.

Ну и конечно стоит помнить о мизерном вознаграждении за подобную деятельность. Обычно это 5-10% от чистого чека привлеченного клиента, хотя существуют и исключительные предложения со ставкой до 40%, но они единичны. Плюс хостер может выставить ограничения на вывод по реферальной программе, как это, например, делает Selectel, и установить кап в размере 10 000 RUB. То есть для того, чтобы получить первые деньги, веб-мастеру надо привести компании клиентов на 100 000 RUB без учета скидок, промо-кодов и акций. Значит, сумму необходимого чека можно смело увеличивать на 15-20%. Это выливается в перспективу никогда не увидеть денег за привлеченных клиентов.

В общем, потенциальных проблем хватает. Технически, принять участие в этой партнерской программе может кто угодно: ведь реферальную ссылку можно распространять в социальных сетях или рекламировать на каналах, в сообществах или на медиа-площадках. Но по факту подобная система полноценно подойдет разве что администраторам узкоспециализированных ресурсов, на которых процент потенциальных покупателей мощностей хостинг-провайдера просто зашкаливает и при условии, что кап на вывод либо отсутствует, либо является чисто символическим.

Прямая реферальная система
Тут все еще проще, чем в баннерной модели. Прямая реферальная система для партнеров подразумевает модель, при которой партнер буквально «за руку» приводит клиента к хостеру, то есть занимает крайне активную позицию в этом процессе. Фактически, прямая реферальная программа — это выполнение функции отдела продаж партнером. Хостеру остается только подписать договор и предоставить клиенту мощности.

В этой модели размеры вознаграждений выше и достигают у некоторых хостинг-провайдеров и дата-центров 40-50% от суммы чека (при условии, что партнер привел много клиентов, кого-то очень большого или покупателя на определенный тариф), или вовсе практикуется единоразовая выплата 100% от месячной стоимости тарифа. Среднее же вознаграждение колеблется на отметке 10-20% с чека.

Основная целевая аудитория подобных реферальных программ — аутсорс-компании, которые занимаются обслуживанием инфраструктуры. Подобная система является жизнеспособной, так как может быть выгодна и конечному клиенту. Например, никто не исключает варианта договоренности между организациями о частичном или полном зачете реферального вознаграждения в счет услуг компании, поставляющей аутсорс-услуги.

Но тут опять есть подводные камни. Например, некоторые хостеры платят только единоразовое вознаграждение, или ограничивают срок выплат, если общий чек по приведенному клиенту или клиентам слишком низкий. Таким образом хостинг-провайдеры пытаются «стимулировать» активность партнеров, а по факту — снижают собственные издержки. Сюда же можно записать и многочисленные ограничения по типу предоставляемых услуг, за которые начисляются реферальные бонусы, оговоренные ограничения по объемам закупок, срокам выплат (обычно это минимум месяц, а иногда — и три), и так далее.

Программы категории White Label
За красивым словосочетанием «White Label» кроется вполне знакомая нам система перепродажи. Этот тип партнерской программы предлагает полностью самостоятельно продавать чужие хостинговые мощности под видом своих собственных. Доходит до того, что хостер гарантирует, что клиент никоим образом не будет пересекаться ни с биллингом, ни с самим брендом конечного поставщика мощностей.

Подобную программу можно назвать в чем-то авантюрной, но имеющей право на жизнь. Правда, в этой модели привлечения рефералов вы получаете все проблемы хостинг-провайдера по биллингу, общению с клиентом, юридической поддержке и так далее без прямого доступа к продаваемому вами товару, то есть без доступа к оборудованию.

По-настоящему жизнеспособной подобная модель выглядит для агрегаторов — достаточно крупных игроков, которые имеют партнерский статус категории «White Label» сразу у ряда популярных хостеров разных ценовых категорий. Такие организации могут предоставлять достаточно большой пул услуг своим клиентам, имеют налаженные связи с технической поддержкой каждого из хостеров. Нельзя забывать и про мощный отдел продаж, который обеспечивает прибыльность всего предприятия.

Кстати говоря, многие хостинг-провайдеры работают по подобной гибридной модели: не имея собственного дата-центра в конкретном регионе (или не имея его вообще), они арендуют стойки под свое оборудование у какого-нибудь крупного игрока или дата-центра, и уже на этом строят свой бизнес. Часто подобные партнеры дополнительно перепродают еще и мощности хостинга-партнера, если собственных стоек по какой-то причине недостаточно.

И что в итоге?
На первый взгляд получается интересная ситуация: участие в реферальной программе нужно всем, кроме конечных покупателей вычислительных мощностей. Кажется, что вся эта история базируется на принципах, схожими с принципами сетевого маркетинга Гербалайф. Но с другой стороны, все не так однозначно.

В первых двух моделях (реферально-баннерной и прямой реферальной) работает система рекомендаций. То есть, партнер хостинг-провайдера как бы говорит «этим хостингом стоит воспользоваться, потому что…» и приводит какие-то аргументы в виде цены, поддержки или физического размещения дата-центра поставщика мощностей. В условиях современной конкурентной среды забота о собственной репутации — первоочередная необходимость. Никто в здравом уме не станет рекламировать откровенно плохого хостера собственным клиентам. Вопрос только в том, стоят ли реферальные отчисления того, чтобы заниматься подобной рекламой чужого бизнеса.

В случае же программы по принципу White Label все намного сложнее. Тут многое зависит от того, как будет работать сам партнер, какой уровень сервиса сможет предоставить в плане поддержки, биллинга и просто тарифов. Как показывает практика — некоторые справляются, другие же — бросают тень на весь отечественный рынок хостинг-услуг.

Нам это важно, потому что у нас есть собственный дата-центр, оборудование и опыт, а вот партнерскую программу мы прямо сейчас активно разрабатываем. Так какой, по вашему мнению, должна быть идеальная реферальная программа для партнера или конечного клиента? Высказывайтесь на Kobyakov@miran.ru


miran.ru

Скидка 10% или Windows Server бесплатно для серверов Xeon E3

Серверы Xeon E3-1230v6 со скидкой 10% или аренда лицензий Windows Server Standard бесплатно.

Тарифы со скидкой:

Xeon E3-1230v6 3.4GHz / 16GB DDR3 / 2 * 3TB SATA — 4943 рублей в месяц
Xeon E3-1230v6 3.4GHz / 16GB DDR3 / 2 * 256GB SSD — 5217 рублей в месяц
Xeon E3-1230v6 3.4GHz / 32GB DDR3 / 2 * 3TB SATA — 6681 рублей в месяц
Xeon E3-1230v6 3.4GHz / 32GB DDR3 / 2 * 256GB SSD — 5766 рублей в месяц

или вместо скидки аренда лицензий Windows Server Standard бесплатно

  • автоматическая установка ОС (CentOS, Debian, Ubuntu, MS Windows Server)
  • установка из собственного ISO образа
  • размещение в дата-центрах МИРАН
  • доступ к серверу по IPMI из личного кабинета
  • гарантированный канал Интернет 100 Мбит/сек
  • локальная сеть 1 Гбит/с между серверами
  • круглосуточная техническая поддержка
  • возможность прямого подключения к любому из 50 операторов связи
  • возможность подключить USB-ключи

Тарифы на сайте miran.ru

Заказать со скидкой возможно до 20 июня 2019 года.
Скидка и действие бесплатный лицензий до 31.12.2019г

Скидки 25% на аренду серверов Intel Xeon E5v4

Серверы Xeon E5-2620v4 со скидкой 25% от 9032 рублей в месяц.

Тарифы со скидкой:

Xeon E5-2620v4 2.1GHz / 32GB DDR4 / 2 * 3TB SATA — 9 032 рублей в месяц
Xeon E5-2620v4 2.1GHz / 32GB DDR4 / 2 * 512GB SSD — 9 000 рублей в месяц
Xeon E5-2620v4 2.1GHz / 64GB DDR4 / 2 * 256GB SSD + 2 * 3TB SATA — 11 015 рублей в месяц

2 * Xeon E5-2620v4 2.1GHz / 64GB DDR4 / 4 * 3TB SATA — 12 890 рублей в месяц
2 * Xeon E5-2620v4 2.1GHz / 64GB DDR4 / 2 * 512GB SSD + 2 * 3TB SATA — 13 837 рублей в месяц
2 * Xeon E5-2620v4 2.1GHz / 128GB DDR4 / 4 * 512TB SSD — 15 667 рублей в месяц

  • автоматическая установка ОС (CentOS, Debian, Ubuntu, MS Windows Server)
  • установка из собственного ISO образа
  • размещение в дата-центрах МИРАН
  • доступ к серверу по IPMI из личного кабинета
  • гарантированный канал Интернет 100 Мбит/сек
  • локальная сеть 1 Гбит/с между серверами
  • круглосуточная техническая поддержка
  • возможность прямого подключения к любому из 50 операторов связи
  • возможность подключить USB-ключи

Все тарифы на miran.ru

Заказать со скидкой возможно до 20 июня 2019 года.
Скидка будет действовать до 31.12.2019 года.

Открываем продажи выделенных серверов на Intel Silver 4114 и Intel Gold 6140

Аренда серверов на процессорах Intel Silver и Gold со скидкой 10%

Миран открывает предзаказ выделенных серверов на процессорах Intel Silver 4114 и Intel Gold 6140. При заказе сервера до 28 декабря 2018 года, мы предоставим скидку 10% до конца 2019 года.

2 × Intel Xeon Silver 4114 2.2 ГГц, 20 ядер, 96 Гб, 2 * 480 ГБ SSD + 2 * 3 ТБ SATA = 21500 руб.
2 × Intel Xeon Silver 4114 2.2 ГГц, 20 ядер, 192 Гб, 2 * 480 ГБ SSD = 26000 руб.
2 × Intel Xeon Silver 4114 2.2 ГГц, 20 ядер, 384 Гб, 2 * 480 ГБ SSD = 38000 руб.

2 × Intel Xeon Gold 6140 2.3 ГГц, 36 ядер, 96 Гб, 2 * 480 ГБ SSD + 2 * 3 ТБ SATA = 26000 руб.
2 × Intel Xeon Gold 6140 2.3 ГГц, 36 ядер, 192 Гб, 2 * 480 ГБ SSD = 32000 руб.
2 × Intel Xeon Gold 6140 2.3 ГГц, 36 ядер, 384 Гб, 2 * 960 ГБ SSD = 49500 руб.

Тарифы выше указаны без учета скидки.

Посмотреть цены по скидками

— выдача серверов после 18 января 2019 года;
— гарантированный доступ в Интернет 100 Мбит/с;
— увеличение скорости доступа до 1 Гбит/с — 7000 руб.
— резервирование блоков питания;
— замена вышедших из строя комплектующих и серверов;
— удаленное управление серверами через IPMI;
— подключаем USB ключи;
— локальная сеть 1 Гбит/с между любым оборудованием внутри дата-центра — 200 рублей за порт;
— возможность прямой кроссировки до любого оператора в дата-центре — от 590 рублей;

Плановые работы по замене ПО маршрутизаторов

Информируем Вас о проведении плановых работ по обновлению ПО на оборудовании компании Миран.
Работы будут проведены в ночь с 26-го на 27-е Июля с 01 часа до 03 часов ночи.
Перерыв связи для услуги Интернет составит не более 15 минут.
Приносим извинения за доставленные неудобства.

Техническая поддержка: support@miran.ru т.490-70-91

Инженерные системы наших дата-центров, часть 2

Trace Mode и с чем его едят
Повторюсь, изначально в в первом дата-центре выраженного мониторинга не было, а необходимость в нем была. И воплощать эту потребность решили сперва на базе уже строящегося «Миран-2», который планировался еще и модульным. Проектировщики и интеграторы предложили в качестве SCADA использовать отечественный Trace Mode. Данный продукт на тот момент мог удовлетворить все хотелки в плане мониторинга, был относительно простым в дальнейшей разработке (ежели бы такая необходимость возникла… и она-таки возникла) и стоил вроде бы не очень больших денег. В общем, неплохой вариант для простой системы.

АРМ дежурного ЦОД «Миран-2».


Trace Mode являет собой вполне классической образчик SCADA, имеет в себе ядро-сервер, опрашивающий циклично все необходимые железки по сети и клиент-консоли на АРМах дежурных, которые всю жизненную информацию от сервера и выводят, в виде различных мнемосхем. Такой вариант исполнения был использован для мониторинга «Миран-2» в целом. Для модульных ЦОД внутри (их пока у нас два) — был использован вариант с «тонкими» клиентами (java-апплет в браузере).

Фото панели с «тонким» клиентом в браузере и панели с клиент-консолью.


Кратко расскажу о внутренней структуре проектов. Есть условно два уровня:
  • нижний уровень, опрос устройств. Осуществляется «Источниками/Приемниками» — некие структурные шаблоны, которые определяют различные протоколы, технологии и интерфейсы (Modbus RTU/TCP-IP, SNMP, DDE, OPC etc.), содержат настройки связи. В общем, являются софтварным отражением периферии.
  • верхний уровень, тэги. В Trace Mode они называются «Каналами». Эти шаблоны уже определяют тип параметра, получаемого от «Источников» (дискретный/аналоговый), задают для него масштабирование, аварийные/предаварийные пределы (для аналоговых сигналов), назначают привязку к словарям аварийных сообщений, наконец, «каналы» же устанавливают будет ли данный параметр архивироваться или нет. Соответственно, к различным графическим элементам на мнемосхемах эти «каналы» можно привязать для оперативного мониторинга.

Trace Mode IDE. «Источники/Приемники».


Trace Mode IDE. «Каналы».


Это и есть ядро SCADA.
Конечно же в Trace Mode есть также возможность писать подпрограммы на общепринятых промышленных языках (ST, LD, FBD), создавать отчеты, рассылать SMS и E-mail.
На заметку.
Все продукты в семействе Trace Mode защищены HASP-ключами. Для работы в IDE требуется свой ключ, лимитирующий в проекте количество источников данных (e.g. лицензия на 128, 256, 512… N устройств). Для работы МРВ требуется свой ключ. Он лимитирует максимальное количество «каналов» в скомпилированном проекте; в подмножество каналов, помимо самих каналов, входят и вызовы программ, шаблонов экранов. Также ключ определяет доступность некоторых технологий, у нас, в частности, возможность запуска OPC-сервера Trace Mode. Для клиент-консолей, которые используются в АРМах, ключ лимитирует число экранов (в проекте дюжина мнемосхем, а ключ на десять? Два экрана перестанут вызываться). «Тонкие» клиенты? Ну вы поняли, ограничения на кол-во одновременных подключений, шаблонов документов...

Изначально, мониторинг от интегратора был довольно прост. Самый минимум: данные о состоянии вводных и вспомогательных автоматов, данные по энергопотреблению, показания температурных датчиков и датчиков влажности, состояние кондиционеров и ИБП, а также (один из важнейших параметров) — по-стоечный расчет энергопотребления.

Т.к. система, конечно же, была неидеальна и страдала от всяческих недоработок, ее нужно было поддерживать и совершенствовать. Здесь на сцене и появляется ваш покорный слуга. Основной моей задачей стало свести количество ошибок в системе к минимуму, а в последующей перспективе — добавить новых глюков фич, которые должны облегчить эксплуатацию всей инженерной инфраструктуры наших дата-центров.

Перво-наперво, система мониторинга была «причесана и вылизана», а именно: исправлены всяческие «очепятки», приведены в соответствие порядок чисел (200 градусов Цельсия в холодном коридоре превращаются в 20,0), найден консенсус, в чем же мы меряем потребление в стойках — в кВт или все-таки в кВА. Спойлер!

Вторым эшелоном шли исправления стратегические. Например, в первоначальной версии проекта первого модульного ЦОД не было никакой индикации о состоянии его ИБП, в норме ли они или уже отключились в аварийном состоянии из-за поломки. Был расширен список возможных аварийных ситуаций и сообщений о многих узлах ЦОД. Мнемосхемы обрастали различными значками, индикаторами и дополнительными параметрами, в общем, всем, что должно было помочь понять — здоров или нет дата-центр.

Основная мнемосхема ЦОД «Миран-2»


Основная мнемосхема ЦОД «Миран-1»


Мнемосхема состояния ИБП узла связи «Миран-2»


Мнемосхема ДГУ-1 «Миран-2»


Всплывающая мнемосхема модульного ЦОД «Модуль-2»


Огромные панели с мигающими мнемосхемами — это очень круто и хорошо, но дежурный все же человек, которому свойственно уставать, забывать и не замечать. Системы мобильных ЦОД не имеют, к сожалению, журнала тревог, поэтому было решено реализовать рассылку аварийных писем, как службе главного инженера, так и в тикетную систему нашей тех.поддержки. В последствии, к этому еще добавилась и оповещающая сирена.

Крутые метрики и все-все-все
После года шлифовки проектов Trace Mode, был достигнут некий удобоваримый компромисс между «хотим красиво, современно и круто» и «реализовали как смогли и как получилось». В целом, система справлялась с мониторингом и оповещением по текущему состоянию, но хотелось иметь и возможность простейшего анализа климатики и энергопотребления.

Т.к. системы модульных ЦОД были оснащены только лишь «тонкими» клиентами и графиков и трендов они не поддерживали (опять же), хоть какой-то анализ был выполнен в виде суточных отчетов на E-mail`ы службы главного инженера (с простейшими табличками, заполненных мин/максами значений по датчикам температур и энергопотребления стоек). Наглядность, впрочем, все равно оставляла желать лучшего. Ко всему прочему, еще одним камнем преткновения стала нестабильная работа собственных архивов Trace Mode, из которых эти данные извлекались.

Перебрав несколько вариантов решения всего этого безобразия, было решено остановиться на варианте с отгрузкой данных из Trace Mode во внешнюю БД для дальнейшей обработки.

Когда я уже хотел приступать к реализации вышеозначенного варианта, наш главный инженер наткнулся на просторах интернета на сайт grafana. Дружно повздыхав над красотой графиков, мы сошлись на том, что-де реализовать подобное под наши нужды на текущей платформе — затруднительно. Тем не менее, grafana крепко засела у меня в голове и я стал искать любые гайды с описанием реализованных решений с ее участием. Переломными стали несколько статей на хабре: 1 и 2 (Хабр окрыляет помогает!) с упоминанием демона collectd и его плагинов.

Теперь уже вполне себе вызрела идея как все это реализовать под наши нужды.


Под все это дело был выделен скучающий от низкой нагрузки blade-сервер и развернута тестовая Ubuntu со всем необходимым набором софта. После этого настал черед заполнить конфиг collectd на предмет что и как ему опрашивать. Ниже некоторые выдержки из конфига. Ничего особенного, все строго в соответствии с документацией по демону и плагинам:

Содержимое файла конфигурации для collectd
# Config file for collectd(1).
#
# Some plugins need additional configuration and are disabled by default.
# Please read collectd.conf(5) for details.
#
# You should also read /usr/share/doc/collectd-core/README.Debian.plugins
# before enabling any more plugins.

Hostname "graphite"
FQDNLookup true
#BaseDir "/var/lib/collectd"
#PluginDir "/usr/lib/collectd"
TypesDB "/usr/share/collectd/types.db" "/etc/collectd/my_types.db"
Interval 10
#Interval 60
#Timeout 2
#ReadThreads 5

LoadPlugin logfile
LoadPlugin cpu
LoadPlugin disk
LoadPlugin memory
LoadPlugin modbus  //тот самый плагин
LoadPlugin snmp
LoadPlugin write_graphite

#LoadPlugin email
#LoadPlugin sensors
#LoadPlugin serial

<Plugin logfile>
    LogLevel "info"
    File STDOUT
    Timestamp true
    PrintSeverity true
</Plugin>

<Plugin modbus>

#DC2 VRU Data -------------------------------------------------

 <Data "VRU-QF1-Status">
   RegisterBase 380
   RegisterType int16
   Type word
   Instance "VRU-QF1-Status"
 </Data>

 <Data "VRU-QF2-Status">
   RegisterBase 381
   RegisterType int16
   Type word
   Instance "VRU-QF2-Status"
 </Data>
…
 <Data "VRU1-U-AN">
   RegisterBase 300
   RegisterType int16
   Type voltage
   Instance "VRU1-U-AN"
 </Data>

 <Data "VRU1-U-BN">
   RegisterBase 301
   RegisterType int16
   Type voltage
   Instance "VRU1-U-BN"
 </Data>

 <Data "VRU1-U-CN">
   RegisterBase 302
   RegisterType int16
   Type voltage
   Instance "VRU1-U-CN"
 </Data>

 <Host "DC2_PLC">
   Address "XXX.XXX.XXX.XXX"
   Port    "502"
   Interval 5
   
   <Slave 1>
    Instance "Vars"
    Collect  "VRU-QF1-Status"
    Collect  "VRU-QF2-Status"
...
    Collect  "VRU1-U-AN"
    Collect  "VRU1-U-BN"
    Collect  "VRU1-U-CN"
...
   </Slave>
 </Host>

<Plugin snmp>
# DC2_Module1_UPS1 -------------------------------------------------
 <Data "UPS1_load_A">
  Type "percent"
  Table false
  Instance "Load_A"
  Values ".1.3.6.1.2.1.33.1.4.4.1.5.1"
 </Data>

 <Data "UPS1_load_B">
  Type "percent"
  Table false
  Instance "Load_B"
  Values ".1.3.6.1.2.1.33.1.4.4.1.5.2"
 </Data>

 <Data "UPS1_load_C">
  Type "percent"
  Table false
  Instance "Load_C"
  Values ".1.3.6.1.2.1.33.1.4.4.1.5.3"
 </Data>
...
 <Host "DC2_Module1_UPS1">
   Address "XXX.XXX.XXX.XXX"
   Version 1
   Community "public"
   Collect "UPS1_load_A"
   Collect "UPS1_load_B"
   Collect "UPS1_load_C"
...
   Interval 5
 </Host>

<Plugin write_graphite>
	<Carbon>
		Host "localhost"
#		Port "2003"
		Prefix "collectd."
		Protocol "tcp"
#		Postfix "collectd"
#		StoreRates false
#		AlwaysAppendDS false
#		EscapeCharacter "_"
	</Carbon>
</Plugin>

Include "/etc/collectd/collectd.conf.d/*.conf"


Дашборд главного ВРУ «Миран-2».


Дашборд с наиболее важными параметрами «Модуль-2».


Дашборд с климатическими трендами «Модуль-2».


Дашборд с трендами по потреблению стоек «Модуль-1».


Подводя итоги
Итак, текущие плюсы решения на collectd + graphite + grafana в сравнении с Trace Mode:
  • Бесплатно (финдир вытирает скупую мужскую слезу счастья).
  • Open Source. Можно теоретически добавить недостающую фичу, написав ее самому.
  • Доступность. По сути, это страничка в браузере для конечного пользователя, а, следовательно, есть у каждого в гаджете в кармане. В Trace Mode поддержки для гаджетов толком нет.
  • Простота и удобство расширения. Достаточно при первоначальной настройке collectd + graphite «скормить» им все необходимые данные — и последующие получившиеся метрики можно редактировать и преобразовывать на лету прямо в grafana. Скажем «Нет!» компиляциям МРВ и клиент-консолей в Trace Mode!
  • Очень неплохие возможности по отображению и анализу графиков «из коробки». Trace Mode в этом плане крайне, хм, консервативен.
  • Есть оповещения и уведомления об аварийных ситуациях во всех новомодных чатиках, по почте etc. Trace Mode же может рассылать E-mail`ы и за отдельную денежку — SMS (если у вас есть необходимое железо).

Минусы:
  • Полновесную SCADA подобной связкой не заменить. Никакого управления тех.процессом. Если, конечно, управление Вам необходимо.
  • Open Source. Ваш покорный слуга не имеет надлежащей квалификации для дописания хотелок, а посему смиренно ждет и/или просит более умных товарищей в git-сообществе.
  • Набор панелей невелик (хоть и расширяется за счет плагинов).
  • Движок алертинга пока очень прост, хитрых условий в нем не настроишь. Разработчики обещают расширить функционал.

Пока решено оставить систему мониторинга неким гибридом из классической SCADA Trace Mode со своими клиент-приложениями и серверами как скрытого от посторонних ядра с АСУ и АСМ и внешней обертки grafana с красивыми и удобными метриками, доступной всем внутри корпоративной сети. К чему в итоге мы придем — покажет время, разных инженерных задач еще хватает.

Инженерные системы наших дата-центров, часть 1

Введение в ЦОДоведение
Что есть центр обработки данных? Говорим «ЦОД» — представляем себе бескрайние ангары, заполненные бесчисленными рядами стоек с мерно гудящими железками. Железки загадочно перемигиваются разноцветными огоньками из полумрака. С лицевой стороны их обдувает прохладным бризом от промышленных кондиционеров. В холодных зонах можно наотличненько просквозить себе шею и простудиться. Поэтому админы всегда носят свитера.

Нашей компанией построены два отдельно стоящих дата-центра, бесхитростно именуемые «Миран-1» и «Миран-2». Первый представляет собой вполне привычный тип, с одним большим машинным залом и несколькими поменьше этажом выше. Второй ЦОД представляет из себя ангар, в котором на данный момент установлены два мобильных малых ЦОДа, а также строится третий. Мобильные ЦОДы — двухэтажные конструкции-контейнеры, первый этаж которых есть серверный зал со стойками и кондиционерами, он еще именуется серверным блоком, на втором же смонтированы ВРУ, установлены ИБП и различные щиты управления.

Так исторически сложилось, что «Миран-1» не имел единого мониторинга инженерной инфраструктуры (посыпаем голову пеплом) и мы стремимся исправить этот недостаток. Посему речь большей частью пойдет о втором дата-центре.

ТП, ВРУ, PDU
В «Миран-2» реализована система гарантированного электроснабжения (СГЭ). Как видно из схемы ниже, в обычных условиях дата-центр питается от двух независимых внешних вводов от ТП; в случае пропадания напряжения на внешних вводах (а такое у нас иногда случается) — питание идет от дизель-генераторной установки ДГУ2, фактически; под будущий задел предусмотрено место для еще двух.


Идем дальше. ВРУ выполнено двухсекционным с секционным выключателем под управлением АВР1. Контроллер АВР замкнет секционник в случае пропадания напряжения на одном или обоих вводах, в последнем случаем через 15 секунд будет дан сигнал на запуск ДГУ. Все эти неприятности «Модуль-1 и «Модуль-2» переживают на своих внутренних ИБП.


Основное назначение секций и их автоматов, помимо питания различных вспомогательных щитов освещения, управления вентиляцией и прочего — исполнять роль вводов электропитания для «Модуль-1» и «Модуль-2» (QF1.1-.2 и QF2.1-.2 на схеме, соответственно). Каждый модульный ЦОД имеет внутри себя свое собственное ВРУ.

Мнемосхема главного распределительного щита «Модуль-2»


Фото главного распределительного щита «Модуль-2».


Мнемосхема энергоблока «Модуль-1»


Мнемосхема стоек «Модуль-1»


Большая часть стоек в «Модуль-1» и «Модуль-2» — производителей Rittal и RiT. Из PDU используем: в «Модуль-1» — сборную солянку из Eurolan, APC, DELTA. «Модуль-2» — целиком на PDU фирмы RiT.

Окунись в прохладу ©
Все клиентское железо, а также инженерная инфраструктура в процессе своей работы выделяют много тепла. Это тепло необходимо отводить, иначе железо быстро умрет. Отводом у нас занимаются шесть инверторных фреоновых кондиционеров фирмы Daikin. Вся их деятельность гордо называется «фреоновым режимом», который обеспечивает сухой тропический прохладный климат от +15 до +23 С° в холодном коридоре. Данная система охлаждения применяется и в «Модуле-1», и в «Модуле-2».

Также в «Модуле-1» существует еще один режим охлаждения, «режим фрикулинга». Его должны обеспечивать четыре приточных установки и дюжина вытяжек. В теории. К сожалению, на практике отвод тепла таким образом был не слишком эффективным, если внутри было задействовано чуть больше половины стоек. Поэтому данный режим для первого модульного ЦОДа так и не используется, оставаясь, по сути, резервным.
Мнемосхема серверного блока «Модуль-1»


Мнемосхема серверного блока «Модуль-2». Никаких приточек, только хардкор! фреон!


От клеммного зажима до ПЛК
Опросом и агрегацией информации от всей периферии дата-центра «Миран-2» занимаются три ПЛК: по одному на «Модуль» и один общий. Эти вундержелезки носят имя небезызвестной компании WAGO.

Рассмотрим структуру системы опроса на основе решения для «Модуль-2».


Схема шины ПЛК с модулями, скриншот из WAGO-IO-Check


Фото щита диспетчеризации «Модуль-2».


Как видно из схемы, на шине установлен сам ПЛК серии 750-881, четыре дискретных модуля 750-1405 на 16 каналов каждый и один аналоговый модуль 750-455 на четыре канала. Через дискретные модули ПЛК получает данные о состоянии автоматических выключателей питания («сухие» дополнительные контакты) в обеих секциях ГРЩ, о состоянии автоматов в собственном щите, а также о состоянии вентиляции энергоблока. Посредством аналогового модуля — получает данные от двух датчиков температуры и влажности (4-20 мА) здесь же, внутри энергоблока.

ПЛК также оснащен двумя Ethernet-портами и через них он общается по Modbus TCP/IP с еще несколькими железяками, как то:
  • два вводных автомата фирмы Schneider Electric, от них же получается информация о входных мощностях, напряжениях, токах и прочем;
  • две системы измерения токов фирмы АВВ в тандеме с двумя модулями ввода от фирмы ОВЕН — результатом их совместного труда есть вычисление по-стоечной мощности;
  • контроллеры CAREL и 6 их подопечных — кондиционеры Daikin;
  • и, наконец, младший братик — каплер 750-342 c семью дискретными модулями. Их задача отслеживать состояние 48 выключателей + 12 резервных в серверном блоке на 24 стойки.

Фото ABB CMS-600 и трансформаторов тока.


Фото ОВЕН МЭ110-220.3М.


Фото ПЛК CAREL.


Фото щита слаботочных систем «Модуль-2».


Отдельно стоит упомянуть ИБП, они опрашиваются непосредственно SCADA, минуя ПЛК, по SNMP-протоколу.


Вся получаемая информация посредством программы формируется в собственный список Modbus-регистров, которая уже опрашивается SCADA.

Небольшой кусочек из основной программы
(* PLC_A2 *)
%QX256.0 := A2_1QF1;	//присваиваем каждому биту 256го слова
%QX256.1 := A2_1QF2;	//текущее состояние различных автоматов
%QX256.2 := A2_QS1;
%QX256.3 := A2_QS2;
%QX256.4 := A2_3QF1;
%QX256.5 := A2_3QF2;
%QX256.6 := A2_3QF3;
%QX256.7 := A2_3QF4;
%QX256.8 := A2_3QF5;
%QX256.9 := A2_3QF6;
%QX256.10 := A2_3QF7;
%QX256.11 := A2_3QF8;
%QX256.12 := A2_3QF9;
%QX256.13 := A2_3QF10;
%QX256.14 := A2_KM1;
%QX256.15 := A2_KM2;

(* QF1 *)   //вводной автоматический выключатель № 1
%QW332 := QF1_I_L1;    //токи по фазам
%QW333 := QF1_I_L2;
%QW334 := QF1_I_L3;
%QW335 := QF1_U_L12;   //линейные (межфазные) напряжения
%QW336 := QF1_U_L23;
%QW337 := QF1_U_L31;
%QW338 := QF1_U_L1;   //фазные (фаза-нуль) напряжения
%QW339 := QF1_U_L2;
%QW340 := QF1_U_L3;
%QW341 := QF1_P_L1;   //активная мощность по фазам
%QW342 := QF1_P_L2;
%QW343 := QF1_P_L3;
%QW344 := QF1_P_Sum;  //суммарная активная мощность (кВт)
%QW345 := QF1_Q_L1;   //реактивная мощность по фазам
%QW346 := QF1_Q_L2;
%QW347 := QF1_Q_L3;
%QW348 := QF1_Q_Sum;  //суммарная реактивная мощность (квар)
%QW349 := QF1_S_Sum;  //полная мощность (кВА)
%QW350 := QF1_CosF;   //коэффициент мощности


Еще один кусочек из другой подпрограммы
//Это работа кодогенератора CODESYS, в котором есть удобный настройщик связи
//с периферией по Modbus TCP/IP. Эта подпрограмма, в частности, отвечает 
//за получение от ОВЕН МЭ110-220.3М показаний 
//по трем напряжениям фаза-нейтраль

PROGRAM MBCFG_subCMS_1(* generated by config one prg for each slave *)

VAR_OUTPUT
U_L1  :  WORD; (**) 
U_L2  :  WORD; (**) 
U_L3  :  WORD; (**)

/*--- system variables (read only) ----------------------------------------*/
MBCFG_IpAddress    :   STRING(12) := 'XXX.XXX.XXX.XXX';//IP-адрес Slave-устройства
MBCFG_Port         :   UINT := 502;               //Порт, дефолтный
MBCFG_UnitID       :   BYTE := 2;                 //ID Slave-устройства
MBCFG_TimeOut      :   TIME := t#300ms;           //Таймаут на получение ответа
MBCFG_RequestDelay :   TIME := t#1000ms;          //Задержка до следующего опроса
MBCFG_Error        :   MBCFG_eERROR := MBCFG_START_UP;
MBCFG_LastJob      :   MBCFG_typCOM_JOB;
/*-------------------------------------------------------------------------*/
END_VAR

VAR CONSTANT
    zz_VARIABLECOUNT:   INT := 3; (* number of variables  *)
    zz_JOBCOUNT     :   INT := 1; (* number of jobs *)
END_VAR
VAR

/*=== VARIABLE LIST =============*/
zz_VariableList :   ARRAY[1..zz_VARIABLECOUNT] OF MBCFG_typVARIABLE :=
    ( DataType        := MBCFG_TYPE_WORD,  
      ByteOrder       := MBCFG_BYTE_ORDER_0,
      BitSize         := 16,
      ptVar           := 0,
      ReadJobIndex    := 1,
      ReadStartBitNo  := 0,
      WriteJobIndex   := 0,
      WriteStartBitNo := 0 ),
   (  DataType        := MBCFG_TYPE_WORD,
      ByteOrder       := MBCFG_BYTE_ORDER_0,
      BitSize         := 16,
      ptVar           := 0,
      ReadJobIndex    := 1,
      ReadStartBitNo  := 32,
      WriteJobIndex   := 0,
      WriteStartBitNo := 0 ),
   (  DataType        := MBCFG_TYPE_WORD,
      ByteOrder       := MBCFG_BYTE_ORDER_0,
      BitSize         := 16,
      ptVar           := 0,
      ReadJobIndex    := 1,
      ReadStartBitNo  := 64,
      WriteJobIndex   := 0,
      WriteStartBitNo := 0
   );

/*=== JOB LIST ==================*/
zz_JobList     :   ARRAY[1..zz_JOBCOUNT] OF MBCFG_typCOM_JOB :=
   (  Functioncode            := 3, //Номер функции, 0x03, Read Holding Registers
      ReadStartAddress        := 26,//Адрес первого регистра
      ReadQuantity            := 5, //Кол-во регистров, которые следует прочесть
      WriteStartAddress       := 0,
      WriteQuantity           := 0,
      ptReadData              := 0, 
      ptWriteData             := 0
   );

zz_DataField_1_Read       :       ARRAY[1..5] OF WORD;

/*=== MODBUS MASTER ==============*/
zz_MBCFG_MASTER_ETH :       MBCFG_MASTER_TCP;

END_VAR

/*--- for each variable -------------------------*/
   zz_VariableList[1].ptVar := ADR(U_L1);
   zz_VariableList[2].ptVar := ADR(U_L2);
   zz_VariableList[3].ptVar := ADR(U_L3);
/*-----------------------------------------------*/

/*--- for each job -----------------------------------*/
zz_JobList[1].ptReadData   := ADR(zz_DataField_1_Read);
/*----------------------------------------------------*/

/*#### START OF FIXED CODE #####################################*/
zz_MBCFG_MASTER_ETH(	strIpAddress    := MBCFG_IpAddress,
                        uiPort          := MBCFG_Port,
                        bUnitID         := MBCFG_UnitID,
                        tTimeOut        := MBCFG_TimeOut,
                        iVariableCount  := zz_VARIABLECOUNT,
                        ptVariableList  := ADR(zz_VariableList),
                        iJobCount       := zz_JOBCOUNT,
                        ptJobList       := ADR(zz_JobList),
                        tRequestDelay   := MBCFG_RequestDelay,
                        eError          => MBCFG_Error,
                        LastJob         => MBCFG_LastJob
                    );

%QW377 := U_L1;
%QW378 := U_L2;
%QW379 := U_L3;

Предупреждение о проведении аварийных работ на сети ООО Миран

Уважаемые клиенты!

В ночь с 07.02 на 08.02.2018 с 01:00 до 02:00 на сети связи компании Миран
будут проведены аварийные работы.

Перерыв в предоставлении доступа к сети интернет, в указанное время, не
более 15 минут.

Работы затронут сервис доступа в интернет клиентов использующих следующие
подсети (IP адреса):

185.147.82.128/25 и 185.169.92.0/24

Приносим извинения за доставленные неудобства.

Скидка 50% на аренду серверов, к примеру Xeon E5v4/32Гб/2х512Гб SSD за 7150 руб/мес

Аренда серверов с процессорами Xeon E5 со скидкой 50% на весь период аренды!
Скидка распространяется только на серверы в наличии, всего 7 серверов, торопись.
  • Intel Xeon E5-2620v4 / 32Гб DDR4 / 2 х 512Гб SSD — 7150 ₽
  • Intel Xeon E5-2620v4 / 32Гб DDR4 / 2 х 3000Гб SATA — 7150 ₽
  • Intel Xeon E5-2620v4 / 64Гб DDR4 / 2 x 256Гб SSD + 2 х 3000Гб SATA — 8450 ₽
  • 2 x Intel Xeon E5-2620v4 / 64Гб DDR4 / 4 х 3000Гб SATA — 9700 ₽
  • 2 x Intel Xeon E5-2620v4 / 64Гб DDR4 / 2 x 512Гб SSD + 2 х 3000Гб SATA — 10300 ₽
  • 2 x Intel Xeon E5 2620v4 / 128Гб DDR4 / 4 х 512Гб SSD — 11500 ₽

Все серверы размещены в собственных дата-центрах в г. Санкт-Петербурге
Каждый сервер подключен с сети Интернет 100 Мбит/с без ограничения по трафику
Серверы могут быть объединены в локальную сеть на скоростях 1-10 Гбит/сек.

Скидка распространяется только на серверы
Дата окончания акции: 13.10.2017 включительно
Подробнее