Итак, как и обещал

Описание текущей ситуации со стабильностью работы:
За последние полгода у нас было, как многие заметили, несколько коротких даунтаймов и один длинный (больше 1 часа), которые приводили к недоступности нашего дата-центра.
Всего было 3 разных причины, которые приводили к даунтаймам. Опишу по порядку сами причины и найденные нами решения, которые не позволят в будущем повториться данным проблемам.

Введение: что такое Juniper и с чем его едят.
1. Самая затяжная проблема, которая и повторялась в течение полугода, возникла на нашем основном магистральном маршрутизаторе Juniper MX960, через который проходит весь трафик нашего ДЦ и всей нашей сети. Сама железка является крайне надёжной, с точки зрения аппаратной части. Он имеет 4 независимых блока питания, две продублированные управляющие платы. Данная модель маршрутизатора является рабочей лошадкой для большинства мировых операторов связи, но в силу специфики и ограниченного количества покупателей в мире выпускается исключительно под заказ. То есть вы не можете просто прийти в магазин и в тот же день забрать данный агрегат. Ожидание поставки подобных устройств может занимать от 2-х до 4-х месяцев после оплаты. То есть, компания Juniper не начнёт производство такого маршрутизатора, пока не получит за него деньги. Стоит такая железка от нескольких миллионов до нескольких десятков миллионов рублей, в зависимости от комплектации.
Приведённое мной описание предназначено в основном для непрофессионалов в сетевых технологиях, чтобы было понимание, что это не просто дешёвая глючная железка, которую мы купили по случаю на барахолке, лишь бы сэкономить на оборудовании (а такие комменты мелькали). Да, этот девайc сродни вашим домашним WiFi-роутерам, только во много раз мощнее, надёжнее и функциональней. Для примера, данный роутер может прокачивать более 10 терабит информации в секунду, в полной комплектации. Ваши домашние WiFi-роутеры будут расщеплены на атомы сразу после подачи такого потока информации (шутка, у самого дома такой же «Зухель» стоит).
Но даже в таких сверхнадёжных девайсах бывают ошибки в программном обеспечении, на одну из которых мы и натолкнулись.

Начало. И начались «Дудосы»!
Все началось с того, что мы стали разрабатывать свою систему защиты от DDoS-атак и фильтрации паразитного трафика. Кто с нами уже давно, тот помнит, сколько проблем было в начале 2016 года, связанных с большим количеством атак, как на наши собственные (привет, недоброжелательные конкуренты ) так и на ресурсы наших клиентов. И вопрос наличия качественной защиты встал ребром.

Здесь я позволю сделать себе еще одно отступление от основной темы, но оно позволит понять цепочку событий, которые привели к возникновению проблемы и пониманию, почему мы двинулись именно в эту сторону.
Существует всего два способа организации DDoS-защиты для хостера:
  1. Использовать внешнюю защиту от какого либо поставщика услуг.
  2. Организовать собственный программно-аппаратный комплекс защиты.
Первый вариант быстр и не требует капитальных вложений, но обладает рядом существенных минусов: значительно поднимает для конечного клиента стоимость услуги, поскольку защита становится ежемесячными операционными расходами в бюджет хостера, и весьма не маленькими. Также, при использовании внешней защиты, невозможно иметь резервный канал связи, поскольку сама парадигма работы систем защиты от атак сильно завязана на сессии, а при наличии двух каналов связи ситуация, при которой входящий трафик приходит через одного провайдера, а исходящий уходит через другого является обычным явлением. Входящий провайдер ничего не знает о том, что была открыта TCP-сессия, ответ по которой ушел через другого оператора. В таких случаях система защиты будет считать весь входящий трафик паразитным и, фактически, происходит полная блокировка защищаемого сервера. Если кто помнит, то мы через это проходили в 2016 году. Из данной проблемы вытекают сразу две: первая, что мы всецело должны зависеть от пиринговой политики «Анти-ддосера» и вторая, очень важная, мы должны отказаться от резерва. Казалось бы, у крупных и уважаемых компаний такая проблема должна быть сведена к минимуму. Увы, это оказалось не так. Опять же, вспоминаем, весну-лето 2016 года. Сначала мы были под защитой DDoS Guard, за неделю словили 4 даунтайма по их вине, вместе со всей их сетью и другими клиентами. На четвёртый раз они позвонили и деликатно попросили нас снять все наши анонсы с них, т.к. они не выдерживают объём нашего трафика и летящих на нас атак. Вывод – данный вариант подойдет не очень крупным хостерам, с чётко понятной спецификой трафика. С 2016 года наш трафик вырос в несколько раз (уже пробивали планку исходящего трафика в 80 Гбит/с). Слышал, что они с тех пор расширили свои мощности, но мы решились только прикрывать ими свои сайты, и только на время настройки собственного решения.
Далее был Ростелеком с его Arbor-ом. Сразу скажу, что связанность РТ существенно хуже нашей. Их пиринговая политика приводит к тому, что с большинством российских операторов они предпочитают общаться через заграничные стыки. Также, за 2 месяца сидения под защитой РТ мы словили 2 даунтайма по их вине, один из которых был очень серьёзным, в тот раз они положили половину своей сети. При звонке в их саппорт нам даже сказали, что тикет зарегистрировать не могут, поскольку у них у самих всё лежит. Далее – скорость реагирования на атаки у Ростелекома крайне не высока, по большинству атак нам приходилось писать письма, потом звонить и «пинать» их спецов, чтобы они руками накладывали нужные фильтры на свой Arbor. Причём в настройке постоянных фильтров нам было отказано, в силу очень большого объёма нашего трафика и большого количества подсетей.
Итог – может мы такие везучие, но скорее всего это говорит о том, что строить свою сеть на моно-связанности и зависеть от одного поставщика услуг для нас неприемлемо, поскольку проблемы возникают у любых компаний, вне зависимости от их размера и значимости. Итак, для нас остался только один доступный вариант – «пилить» своё решение.

Против лома нет приёма, если нет другого лома!
Ну а теперь ближе к делу. Для организации базовой защиты от DDoS-атак, нами было принято решение использовать возможности имеющегося у нас Juniper MX960. Для получения нужного функционала для фильтрации трафика нами была выбрана одна из стабильных прошивок (на тот момент времени) — 14.2R3. Обновление прошивки было произведено в начале осени 2016 года. В то же время мы существенно расширили каналы связи до нашего ДЦ – 160 Гбит/с. Как раз с того момента многие наши клиенты обратили внимание на существенно возросшую стабильность сети. Благодаря более широким каналам и грамотной настройки фильтров на обновлённом Джунипере, нашим сетевикам удалось добиться существенного повышения доступности нашего ДЦ. В течение этого времени фильтры постоянно улучшались, было произведено несколько минорных обновлений прошивок, для улучшения стабильности и расширения функционала. Хочу заметить, что некоторые из наших клиентов кто разбирается в Джуниперах, активно помогали нам с настройкой фильтров и давали полезные рекомендации для защиты тех или иных протоколов и приложений, за это им наше огромное спасибо. И до весны этого года практически не возникало серьезных проблем связанных с сетевой инфраструктурой. Сеть работала стабильно, фильтры постепенно совершенствовались. Но…

…Песец (маленький пушной зверёк ) подкрался незаметно…
Начиная, где-то с конца весны 2017 года, начали происходить спонтанные перезагрузки линейных карт (это те самые платы, куда втыкаются провода из мира и провода из ЦОДа и через них проходит весь трафик). Эти перезагрузки и выражались в 15-минутном даунтайме ДЦ. Перезагрузка плат как раз занимает эти самые 15 минут, в течение которых и не может передаваться через неё трафик. Природа данного поведения была не ясна, из логов самого джунипера толковой информации получить не удавалось. Мы рассматривали все варианты, от скачков напряжения (но откуда они на чистом питании?) до глюков железа и софта. Поначалу они были редки и спонтанны. С каждым разом Джунипер обвешивался дополнительными мониторингами, наши сетевики днями и ночами перерывали Интеренет и закрытый портал Джунипера в поисках решения данной проблемы. В течение всего лета мы поменяли много прошивок, откатывались на более ранние и ставили самые последние (от части отсюда и частые сетевые работы, которые мы объявляли), но проблема возникала вновь и вновь. И чем дальше, тем чаще она возникала. В итоге, ближе к концу лета, при очередном падении было замечено, что непосредственно перед перезагрузкой линейной карты на ней не было свободно ОЗУ. Это и вызывало автоматический ребут карты. Как раз в тоже время ребята наткнулись на описание исправления подобной проблемы в одном из последних багфиксов прошивки 14 версии. Проблема имеет номер PR1287192 (у кого есть вход на закрытый портал Juniper, может с ней ознакомиться). В этом релизе указано, что ошибка с утечкой памяти исправлена в прошивке 14.2R7-S8. Конечно же, мы сразу обновились до этой прошивки и… в сентябре она произошла снова! Причем последний сбой произошёл неприлично быстро после предпоследнего (пардон, за тавтологию %)). Последний раз это произошло вечером 26 сентября. В это время я только уехал на встречу, на которой собирался продуктивно обсудить «протекание вселенских потоков космических энергий под сводами Большого театра», а вместо этого, в течение часа, координировал действия всех сотрудников в связи со сложившейся ситуацией. После ряда звонков и оперативных совещаний было выработано совместное решение на экстренное обновление нашего любимого Джунипера до самой свежей стабильной прошивки 17 версии, которая вышла за два дня до этого. В ночь 27 сентября мы объявили экстренные сетевые работы, потому как тенденция показывала, что если ничего не предпринимать, то следующий даунтайм может произойти в любую минуту. Итак, обновление прошло успешно и…

Свершилось чудо! Друг спас жизнь друга!
Как показала статистика загрузки ОЗУ линейных карт на Джунипере, начиная с 27 числа, утечка памяти исчезла! И в текущей конфигурации Джунипер показал стабильную работу. Виват! Хэпи энд! Поднимаем бокалы с.., кому с чем нравится, и пьём за долгую и стабильную работу нашего любимого МХ-ика. Но…

Маленькие пушные зверьки любят ходить парами…
2. Теперь переходим ко второму эпичному случаю, который произошел в прошлую пятницу, вечером, 30 сентября.
Если я вас уже утомил своим длинным рассказом, то спешу заверить, что описание второй проблемы будет существенно короче.
В то же самое время у нас подходил к финальной стадии проект, связанный с выведением в отдельный сетевой контур части выделенных серверов клиентов. Необходимость в этом возникла в связи с быстрым ростом объёма серверов в нашем ДЦ, количество которых скоро перевалит за тысячу и необходимостью плавного перераспределения трафика на второй маршрутизатор (тоже Джунипер, но поменьше, MX80). Для плавного переброса трафика была разработана целая схема, с кучей настроек. Поскольку дедлайн по проекту был установлен на конец сентября, но в силу некоторых причин проект был затянут, это привело к тому, что финальные настройки выполнялись в пятницу вечером. И тут сошлось несколько факторов: со стороны руководства компании (в том числе и с моей, непосредственно) было сильное давление на админов о необходимости закончить проект в срок. В итоге сетевой инженер делал финальные настройки из офиса, потому как в этот день у него была необходимость работать в непосредственном контакте с программистами, которые также участвовали в этом проекте. На текущий момент времени наш офис и ЦОД расположены на некотором удалении друг от друга.
И вот сижу я дома, опускаю пакетик чая в чашку с кипятком, наслаждаюсь пятничным вечером… и тут, снова ложится ЦОД… Ну вот уже совсем не смешно становится! Только сказали, что всё исправлено, а тут снова! Что делать, несколько коротких звонков, сообщений в чаты компании. Выясняю, что квалификации дежурного инженера не хватает для перезагрузки Джунипера (ситуация крайне редкая, и дежурные инженера к нему почти никогда не подходят). Бросаю чай, прыгаю в машину, давлю тапочку в пол, мчусь к офису, забираю сетевика, снова давлю тапочку, летим в ЦОД, хорошо, что еще время ночное и пробок нет. В общем вы понимаете, что из одного часа и 20 минут, которые длился даунтайм, координация действий и дорога до ДЦ заняла порядка 40-50 минут.
Всё остальное многие и вас уже видели своими глазами, а кто не видел, может посмотреть запись прямого эфира в нашей группе в ВК (https://vk.com/ihor_hosting?w=wall-40099160_6364). Ну и дабы не скучать, мне пришла в голову идея сделать вам обзорную экскурсию по нашему ДЦ, а то на фотографиях на сайте показано далеко не всё и они уже старые. Да и некоторые товарищи ворчат, что мол фотки не наши, а ДЦ у нас в подвале, в размере полутора стоек, с освещением в виде одной лампочки Ильича и одним ИБП Ippon на 400 Вт (да и тот, наверно, с дохлыми батареями), а счётчики активных услуг на главной странице сайта – это фэйк, сделанный исключительно для красоты и обмана посетителей. А так, вы воочию смогли увидеть всё наше хозяйство и мы даже вместе покрутили дизель, спалив при этом литров 5 солярки. Хотел ещё показать вам, как красиво моргает наша тысяча серверов при полностью выключенном освещении, да телефон сел, ну и все устали уже. Главное, что всё закончилось хорошо…

А чай, таки, остыл…
В последующие дни мы провели полное расследование данного инцидента, в ходе которого было выяснено, что ошибок в конфигурации Джуника, сделанных нашим сетевиком, не было. Однако проведённое изменение конфигурации привело к спонтанному падению процесса, отвечающего за BGP-маршрутизацию. Это и привело к недоступности ДЦ. Такие ситуации и наводят на мысль, что пушные зверьки ходят парами, и судя по всему, мы наткнулись на очередную редко-воспроизводимую ошибку в прошивке, но уже самой последней версии. В связи с этим было принято решение свернуть данный проект, во избежание повторения ситуации. Сетевым инженерам сделано строгое предписание, все серьёзные работы с магистральным оборудованием производить только в непосредственной близости от самого оборудования. Дальнейшие изменения конфигурации Джунипера – свести к минимуму.
В общем – выводы сделаны, головы полетели, компенсации розданы…

И маленькая серая мышка пробежала вслед за песцами…
3. Ну и третий, позавчерашний недодаунтайм, как я писал постом выше, нередкая на наших московских просторах ситуация – обрыв оптики. Но благодаря наличию второго независимого оптического кабеля, который никак не пересекается с первым, простоя работы не было. К сожалению, опять же, как я писал выше, в таких случаях протокол BGP не умеет перестраиваться мгновенно. Интернет пока ещё не настолько совершенен, чтобы в нём не было «ни единого разрыва».

И немного позитива, в качестве эпилога.
Чтобы у вас не складывалось впечатление, что у нас только пушные зверьки по ЦОДу бегают, небольшой список того, что нам удалось добиться за последнее время.
  1. Решена проблема со спонтанной перезагрузкой нод из-за нехватки памяти (ситуация возникала далеко не на всех нодах, но некоторые наши клиенты столкнулись с этим). Нашим админам удалось подружить технологию KSM c панелями VMmanager, от компании ISPsystem. Это дало гарантированный резерв по ОЗУ для всех VDS на ноде.
  2. Опять же, админы отловили странный баг в сетевом драйвере, который проявлялся только на серверах марки ASUS и выражался в коротких разрывах сетевого соединения на VDS, которые находились на этих серверах.
  3. Наверно самая главная новость сентября. Мы, наконец-то, ввели в коммерческую эксплуатацию комплекс AntiDDoS S8080 от компании Huawei! Да! Да! Эпопея, которая длилась целых полтора года, увенчалась успехом. Весь сентябрь и по сей день ребята продолжают накачивать его защитными фильтрами. В течение сентября нами уже было отбито более 3700 атак на ресурсы наших клиентов! Большая часть атак отбивается в автоматическом режиме. При отсутствии атаки трафик проходит напрямую и не подвергается никакой фильтрации. В случае начала атаки, происходит автоматический переброс трафика под защиту Huawei. Фактически, мы являемся самым первым Российским хостером (ну или одним из первых, вдруг, кого-то пропустил ) который обладает полностью своей защитой от DDoS-атак, которая расположена в нашем собственном ДЦ.
  4. Написание собственной панели управления сдвинулось с мёртвой точки и скоро мы откроем доступ в нее для всех клиентов. Сейчас это, конечно, некая инфраструктурная основа, которая теперь будет постепенно наполняться разными инструментами. Со временем вся работа с нашими ресурсами будет переведена в неё. Первые два инструмента, которые станут доступны нашим пользователям, это удобный агрегатор аккаунтов BILLmanager. Это будет удобно для вебмастеров, которые обслуживают много клиентов и вынуждены часто переключаться между аккаунтами путём выхода из биллинга. Также, данный инструмент будет доступен для панелей VMmanager, если у вас много VDS на разных кластерах, то вы сможете легко открывать нужную панель без ввода логина и пароля.
Второй инструмент, над которым завершают работу наши доблестные программисты, будет полезен пользователям услуг выделенных серверов, он позволит контролировать расход трафика (который у нас получился, наверное, самым дешёвым в России и конкурирует по цене с зарубежными ДЦ) и просматривать графики загрузки канала сервера, обновляемые раз в 5 минут. А в последствии и в реальном времени.

Дальше – больше!
Мы работаем для вас, и каждый день стараемся сделать наш сервис лучше!
Всегда Ваш,
Генеральный директор
ООО «ТК МАРОСНЕТ» и Айхор Хостинг
Иван Лунгов

Now shipping: Compute Engine machine types with up to 96 vCPUs and 624GB of memory

Got compute- and memory-hungry applications? We’ve got you covered, with new machine types that have up to 96 vCPUs and 624 GB of memory—a 50% increase in compute resources per Google Compute Engine VM. These machine types run on Intel Xeon Scalable processors (codenamed Skylake), and offer the most vCPUs of any cloud provider on that chipset. Skylake in turn provides up to 20% faster compute performance, 82% faster HPC performance, and almost 2X the memory bandwidth compared with the previous generation Xeon.1
96 vCPU VMs are available in three predefined machine types:
  • Standard: 96 vCPUs and 360 GB of memory
  • High-CPU: 96 vCPUs and 86.4 GB of memory
  • High-Memory: 96 vCPUs and 624 GB of memory


cloudplatform.googleblog.com/2017/10/new-compute-engine-machine-types.html

Yes, Backblaze Just Ordered 100 Petabytes of Hard Drives

Our First 10 Petabyte Backblaze Vault
Ken clicked the submit button and 10 Petabytes of Backblaze Cloud Storage came online ready to accept customer data. Ken (aka the Pod Whisperer), is one of our Datacenter Operations Managers at Backblaze, and with that one click he activated Backblaze Vault 1093, which was built with 1,200 Seagate 10 TB drives (model: ST10000NM0086). After formatting and configuration of the disks, there is 10.12 Petabytes of free space remaining for customer data. Back in 2011, when Ken started at Backblaze, he was amazed that we had amassed as much as 10 Petabytes of data storage.

The Seagate 10 TB drives we deployed in vault 1093 are helium-filled drives. We had previously deployed 45 HGST 8 TB helium-filled drives where we learned one of the benefits of using helium drives — they consume less power than traditional air-filled drives. Here’s a quick comparison of the power consumption of several high-density drive models we deploy.


400 Petabytes of Cloud Storage

Создайте имидж надёжной организации с доменом .ORG всего за 299 рублей



Создайте имидж надёжной организации с доменом .ORG за 299 рублей!
Компания REG.RU объявляет о продлении акции на домены .ORG. Благодаря специальному предложению каждый может зарегистрировать до 31 декабря 2017 года понравившийся веб-адрес более чем в 2 раза дешевле — всего за 299 рублей! Такое имя для сайта подойдёт сайтам социальных учреждений, благотворительных фондов, студенческих групп, opensource-разработчиков и практически любой некоммерческой организации. Зарегистрируйте домен по минимальной цене и получите яркую площадку для вашего проекта!
www.reg.ru/domain/new/ORG/

Главные новости. Сентябрь 2017



В сентябре мы запустили сервис Feature Request, добавили поддержку Debian 9 в ISPmanager Lite и возможность выпускать разные SSL-сертификаты для одного IP-адреса во все продукты. В ноябре команда ISPsystem участвует в конференции WHD.moscow 2017 и проводит круглый стол в Москве.

Оставьте заявку на улучшение продуктов ISPsystem

В ISPsystem начал работать сервис Feature Request. В нём можно предложить улучшение для продуктов ISPsystem и проголосовать за идеи других пользователей. В системе реализованы удобный поиск, теги и комментирование. Вы можете оставить пожелание и следить за его статусом или подписаться на уведомления интересных вам топиков.

Автоматизация маркетинга с BILLmanager

Маркетолог ISPsystem Надежда Пак описала инструменты автоматизации маркетинга в BILLmanager. Благодаря ним биллинговая платформа от ISPsystem помогает увеличить продажи без дополнительных вложений. Материал будет интересен провайдерам хостинга, VPS, VDS, облаков и вендорам программного обеспечения.

Встречаемся на WHD.moscow 2017
ISPsystem примет участие в крупнейшей конференции в сфере хостинга в России WHD.moscow 2017. Конференция пройдет 9 ноября в Москве в отеле «Holiday INN».
Приглашаем провайдеров и пользователей панелей ISPsystem посетить конференцию и встретиться с нашей командой, чтобы обсудить тенденции рынка и узнать больше о продуктах.
Для клиентов и партнеров ISPsystem вход бесплатный.
worldhostingdays.com/moscow/

Круглый стол ISPsystem в Москве
10 ноября мы встретимся с клиентами ISPsystem в Москве. В формате круглого стола обсудим тенденции рынка хостинга и виртуализации, расскажем о возможностях шестого поколения VMmanager и BILLmanager.

На вопросы ответят генеральный директор ISPsystem, руководители разработки и UX-отдела, а также менеджеры по развитию продуктов.

Приглашаем на встречу провайдеров и пользователей панелей ISPsystem. Регистрация уже открыта. Зарегистрированным участникам мы сообщим время и место, пришлём программу и напомним о встрече.
docs.google.com/forms/d/e/1FAIpQLScFL8cD6mimGGOivHTRrliIpYRIsV7g1UQOEmwuLjSRyPLxtg/viewform

Общее для всех продуктов
Настройка SNI. С версии 5.124.0 все панели ISPsystem поддерживают Server Name Indication (SNI), расширение компьютерного протокола TLS. SNI позволяет выпускать разные SSL-сертификаты для разных доменов на одном IP-адресе. Возможность доступна в CentOS 7, Debian 8 и Ubuntu 16.04.

Сертификаты для адресов панелей. С 2016 года в продуктах ISPsystem реализован быстрый выпуск SSL-сертификатов от Let's Encrypt для доменов. Теперь сгенерировать бесплатный SSL можно и для адресов самих панелей ISPsystem. Пользователь с правами root может добавить сертификат напрямую из модуля управления адресами панели. Детали подключения отражены в документации. (5.124.0)

ISPmanager
Улучшение плагина Let's Encrypt. В модуль интеграции с Let's Encrypt добавлены две возможности. Пользователи ISPmanager могут выпускать сертификаты для почтовых доменов, а также подтверждать владение доменом через DNS. Работа плагина Let's Encrypt описана в документации. (5.123.0)

Поддержка CAA-записей в модуле “Домены”. DNS-запись CAA ограничивает круг удостоверяющих центров, которые могут выпускать SSL/TLS-сертификаты для домена. С 8 сентября 2017 года все центры сертификации обязаны проверять CAA-записи. Это предотвратит несанкционированную выдачу SSL — случайную или намеренную. Подробнее о добавлении CAA-записей читайте в документации. (5.121.0)

Почтовые уведомления. К списку доступных почтовых уведомлений добавилось еще одно: уведомление о закончившемся свободном месте на диске и в почтовых ящиках. Оценка места проходит каждые 24 часа. Уведомления включаются индивидуально для root, каждого реселлера и пользователя. Письма уходят только на подтвержденные адреса. (5.121.0)

Поддержка Debian 9. 19 сентября вышла Beta-версия ISPmanager Lite 5.123.0 с поддержкой дистрибутива Debian 9. Поддерживается установка только на чистый сервер. Не рекомендуем обновлять сервер с Debian 8 до Debian 9, если на нем уже установлен ISPmanager Lite. Это может привести к некорректной работе панели. Подробности в новости.

BILLmanager
Платежные системы. Улучшены модули интеграции с PayMaster и SimplePay. Теперь в этих платежных системах можно оформить возврат средств. В SimplePay добавлена поддержка рекуррентных платежей. (5.123.0)

Отправка счета в формате PDF. Для администраторов добавлена кнопка «Отправить счёт». При нажатии отправляет на почту пользователя счёт в формате PDF. При постоплатном выставлении счета PDF-файл прикрепляется автоматически. (5.124.0)

Запрет регистрации. Владельцы биллинга могут запретить регистрацию пользователей по домену email или IP-адресу. Если указать домен, то система откажет в регистрации пользователю с почтовым адресом из этого домена или любого из его поддоменов. Если указать один или сеть IP-адресов, то BILLmanager заблокирует регистрацию с устройства с таким или входящим в сеть IP-адресом. Блокировка регистраций доступна в меню “Настройки”. Все внесенные домены и адреса можно редактировать и удалять. (5.123.0)

DCImanager
Процессоры Intel. DCImanager поддерживает новые процессоры Intel из семейства Gold, Platinum, Silver, Bronze и др. Список всех поддерживаемых устройств доступен в “Справочнике процессоров”. (5.124.0)

Проксирование IPMI через дополнительный сервер. Добавлена опция монтирования ISO-образов на сервер проксирования: после включения опции при проксировании через noVNC становится возможным монтирование ISO-образов из DCImanager на целевой сервер через IPMI (если IPMI поддерживает данный функционал). (5.123.0)

Новые партнеры ISPsystem
В июне к партнерской программе присоединились:
  • mClouds.ru
  • FREEhost
  • Core-VPS
  • UH.ua
Наши партнеры получают скидки на программное обеспечение ISPsystem и бесплатную техническую поддержку.
Узнайте больше: Партнёрская программа для хостинг-провайдеров.

Нужен хостинг? Скидка 50% на все виртуальные серверы

Любой виртуальный сервер со скидкой 50%! Просто выберите тариф VDS Linux (от 173,5 руб./месяц), VDS Windows (от 633,5 руб./месяц с лицензией) или VDS CMS (от 173,5 руб./месяц), переключите ползунок с периодом оплаты на 1 год и воспользуйтесь нашей виртуальной инфраструктурой на свое усмотрение!


Акция действует до 15 октября 2017 только на вновь созданные серверы с единовременной оплатой за год.
cloudlite.ru/services/vds_new

В стоимость каждого тарифа VDS входит:
  • безлимитный трафик на гарантированной скорости 10 Мбит/сек;
  • IP-адрес;
  • DNS-хостинг;
  • лицензии Ubuntu, CentOS, Windows;
  • почасовая тарификация (за выключенный сервер вы платите меньше);
  • техподдержка;
  • ​​​детальный SLA с гарантией доступности 99,95%.