RUvds Хостинг

В индустрии есть устоявшееся мнение, что HDD — это устаревающая технология.

Это с одной стороны. С другой стороны, много у кого написано «Медленные SSD», а по факту при тестах они начинают показывать характерные скорости HDD, характерные бутылочные горлышки HDD и вообще ведут себя как жёсткие диски.

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

При этом мы используем HDD для долговременного хранения.

Основная проблема HDD — это механика
Внутри идут вращение шпинделя, позиционирование головки, трение. Из-за этого количество операций ввода-вывода IOPS физически ограничено.

• HDD выдаёт около 150–200 IOPS. Задержка — миллисекунды.
• SSD (SATA/SAS) — десятки тысяч IOPS.
• SSD NVMe — сотни тысяч IOPS.

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

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

Изменился сам веб. Если раньше мы на низком уровне по факту работали с крупными файлами и нагрузка ложилась на оперативку, то сейчас из-за Докера и k8s нагрузка стала дробной. Плюс очень многое стало возможным перераспределять на диски, зная, что они потенциально быстрые. Контейнеры, слои образов, логи микросервисов генерируют огромное количество мелких операций random I/O. Запускать кубера на механическом диске — технически плохая идея: диск просто не справится с очередью запросов, и iowait съест производительность процессора, даже если канал свободен.

Что можно сделать
HDD можно соединять в быстрые RAID (с дублированием). ОК, мы давно так делаем, ограничения — те же, просто чуть расширяются.

Есть устройства класса SSD+HDD или оперативка + HDD, где контроллер выступает кэшем. Условно, у вас есть 10 ТБ-накопитель, у которого 10 ГБ — это кэш контроллера (либо 1 ТБ — быстрый SSD, а остальное — хард, бывают разные вариации). Если вы пишете, скажем, 5 ГБ — их хватает контроллер, записывает в быструю память и потом постепенно распихивает по медленной. Если нагрузки неравномерные, как на десктопе, то всё прекрасно, со стороны это быстрый на запись диск и как-повезёт-на-чтение диск (попали в кэш или нет). То есть он как бы сам внутри себя делит данные на «горячие» и «холодные».

Вариантов там много, но мы такого не используем. Во-первых, они не предназначены для нормальных энтерпрайз-применений, когда запись-чтение может идти постоянно 24 часа в сутки и в разные места: в этой ситуации кэш быстро прокручивается, и вы работаете с HDD почти напрямую. Во-вторых, они создают дополнительные точки отказа, например, очень сложно объединяются в RAID. Рассинхрон кэша и основного диска может привести к полной потере данных. Отказ SSD-кэша делает недоступным весь массив. В-третьих, это зоопарк. А зоопарк мы очень не любим.

В итоге мы оставляем только SSD и NVMe
У нас наш тариф HDD — на самом деле постепенная миграция с HDD на SATA SSD. Мы искусственно режем скорость и IOPS до уровня хорошего жёсткого диска.

Почему так:

• Нам проще и надёжнее обслуживать парк SSD (нет движущихся частей, ниже риск внезапного отказа), чем поддерживать зоопарк из разных типов накопителей. Исторически мы очень сильно стремимся к гомогенности железа, потому что это очень сильно облегчает и разработку, и ремонт-обслуживание, и логистику, и закупки, и вообще всё в хостинге.
• Если мы переведём всех на быстрый SSD, то нам придётся поднять цены, и тогда клиенты уйдут. На рынке есть умолчание, что есть дешёвый дисковый тариф, но его как раз ограничивают, чтобы он не конкурировал с дорогими. Это искусственное ограничение из-за того, что все так делают — вероятно, в ближайшие годы оно уйдёт.
• Есть привычки клиентов. Пользователь видит HDD и интуитивно считывает это как набор параметров + это дёшево и много места. Когда написано SSD — в голове вообще ничего не всплывает. Если тот же тариф назвать «Медленный SSD» или «Throttled SSD», то это вообще никак не поможет UX. HDD тут с годами стал просто красивой метафорой. Хотя на некоторых серверах они ещё остались.

А лента, лента для холодного хранения?
Удел HDD сейчас — долгое холодное хранение. Мы оставим пул HDD в хостинге как раз для этого. По большей части — для бэкапов. Это бэкапы, архивы логов, старый медиаконтент. Там, где нужно дёшево хранить терабайты и редко к ним обращаться, механика по-прежнему выигрывает по цене за гигабайт.

У нас сейчас есть услуга, где можно получить очень много места дёшево для архивов — это как раз массив классических механических HDD, на котором выделяется виртуальный ресурс.

Но в бэкапах есть другая технология холодного хранения — старая добрая магнитная лента. Много кто действительно хранит на ней — за этим, например, замечены Google или ЦЕРН.

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

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

Поэтому там, где надо дешевле, у нас только HDD.

Но ведь HDD дают безлимитное хранилище!
Это просто дикая боль.

Приходят клиенты и говорят, что на рынке есть тарифы с безлимитным хранилищем.

Это, если что, физически невозможно. Ну, без потерь данных.

В физическом мире безлимитов не существует. Канал (скорость записи) имеет ёмкость, а диск имеет объём. На уровне гипервизора всегда стоят жёсткие лимиты, чтобы один активный клиент не положил сервер и не лишил ресурсов остальных соседей. Безлимит — это всегда маркетинг. Вам дадут пользоваться ресурсом, пока вы не начнёте мешать другим и в разумных рамках.

HDD никаким образом не означает безлимит. Но да, часто само слово означает для клиента «бюджетное хранилище».

Итого

• Самые дорогие тарифы — NVMe-диски. Никто нормально не решил проблему объединения их в массивы с избыточностью, поэтому, если вылетает один такой диск, теряются данные. Рядом с ними обычно стоят HDD для бэкапов по расписанию, например, раз в сутки или итеративных раз в четыре часа.
• Обычные тарифы — SSD-массивы, мы перешли на RAID 10. Вот пост, почему мы так сделали. С них можно подключиться к хранилищу на HDD и получить там виртуальный диск, где физика будет на механических дисках.
• Дешёвые тарифы — те же SSD-массивы и иногда уже выводящиеся из эксплуатации HDD. В будущем — только SSD-массивы.
• Технические диски — образы операционок, промежуточные бэкапы и так далее — иногда бывают классическими HDD.

ruvds.com/ru-rub

Панель управления и администрирования Linux-серверов ispmanager стала доступна в обновленном интерфейсе.

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



Команда разработчиков вносила изменения с целью сделать дизайн одинаково удобным для пользователей с разными особенностями восприятия.
Обновлённый ispmanager корректно работает на устройствах с любым разрешением экрана. Смартфон, ноутбук или большой монитор — панель автоматически подстраивается под используемый формат.

Широкие возможности кастомизации позволяют не ограничиваться выбором между светлой и темной темой – пользователь может настроить цвета и оформление панели под себя или свой бренд, создавая собственное уникальное рабочее пространство.

Релиз нового интерфейса состоялся на 3 марта (версия 6.139, beta). После ближайшего обновления в панели управления появилась иконка с предложением перейти на новый интерфейс.

ruvds.com/ru-rub

Хостинг-провайдер VPS серверов RUVDS совместно с Университетом морской практики и Арктического туризма и компанией «Стратонавтика» приступил к испытаниям возможностей экспериментального дата-центра, собранного в концепции минимального энергопотребления, для решения научных задач в условиях необходимости минимизации влияния на окружающую среду Антарктиды.

Вычислительные мощности компании запущены на станции Беллинсгаузен. Оборудование было доставлено на станцию в два этапа: сначала – самолётом из России в Аргентинский город Ушайя, а затем – морским путём, через Пролив Дрейка, одним из самых опасных маршрутов в мировом океане.

«Мы подходили к проекту подготовленными, уже имея за плечами опыт запуска ЦОД на Северном полюсе. Но с Антарктидой, конечно, всё было сложнее: сказывались и логистические трудности, и в целом большая масштабность проекта. Наш дата-центр предназначен как для решения научных задач, так и для доступа обычных пользователей. Рассчитываем, что локация в Антарктиде прослужит несколько месяцев, после чего оборудование будет безвозмездно передано в пользование сотрудникам станции», – сообщил генеральный директор RUVDS Никита Цаплин.

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

«Это был непростой маршрут. Благо, всё прошло благополучно, и сервер готов к работе с пользователями. Конечно, это экспериментальный некоммерческий проект, но, являясь настоящим дата-центром, служит доказательством перспектив работы серверного оборудования в самых тяжелых условиях. Уверен, этот опыт пригодится в том числе и для освоения Русского Севера», – подчеркнул Денис Ефремов, основатель «Стратонавтики».

ruvds.com/ru/

Вот и прошли очередные двенадцать месяцев, и мы снова поздравляем наших коллег, клиентов и партнеров – друзей, с которыми мы имели честь пронестись через ритмичный 2025-й.

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

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

С праздником!

ruvds.com

В прошлый понедельник у нас случилась очередная крайне идиотская авария. Идиоты тут мы, если что, и сейчас я расскажу детали.

Пострадало четыре сервера из всего ЦОДа — и все наши публичные коммуникации. Потому что владельцы виртуальных машин пришли под все посты и везде оставили комментарии.
Параллельно была ещё одна история — под статьёй про то, что случалось за год, написал человек, мол, чего у вас всё постоянно ломается. Я вот размещаюсь у регионального провайдера, и у него за 7 лет ни одной проблемы.

Так вот.

Разница в том, что мы про всё это рассказываем. Тот провайдер наверняка уже раз 10 падал, останавливался и оставался без сети, но грамотно заталкивал косяки под ковёр.
Это значит — никаких блогов на Хабре, никаких публичных коммуникаций с комментариями (типа канала в Телеграме), никаких объяснений кроме лицемерных ответов от службы поддержки и т.п. И тогда, внезапно, вас будут воспринимать более стабильным и надёжным.

Наверное.

Ну а я продолжаю рассказывать, что у нас происходило. Добро пожаловать в очередной RCA, где главное в поиске root cause было не выйти на самих себя. Но мы вышли!

Сбои случаются у всех, но не все про них рассказывают
До понедельника было другое событие.

Место действия — наш ЦОД в Королёве. Он находится на территории особо охраняемого завода. Завод, как и ЦОД, запитан от двух независимых подстанций + у нас есть ИБП, дизели и запас топлива + договор на поставки топлива и аренду дополнительного резервного дизеля.
Тестовые прогоны дизелей случаются регулярно как минимум на смене топлива с летнего на зимнее.

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

Для нас важно то, что обе подстанции перестали подавать электричество в позапрошлый четверг.

ЦОД в Королёве переключился на дизель и почти 4 часа так работал с перерывами на попытки включения линий подстанций несколько раз. Подачу питания восстанавливали несколько раз, мы выжидали, переходили на городской ввод, и несколько раз происходило повторное отключение и снова переход на дизель.

Примерно через 4 часа подача питания от подстанций была восстановлена и оставалась стабильной. Авария закончилась.

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

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

• ИБП — старых добрых батареях. Что произошло:
• При первом отключении батареи частично разрядились, ЦОД перешёл на дизель.
• Батареи начали заряжаться от дизеля.
• Они не успели полностью зарядиться, ЦОД перешёл на городской ввод.
• Ещё 10 минут они заряжались от города.
• Затем снова переход на дизели, то есть они разряжаются до примерно 20–30% остаточной ёмкости, потому что не успели зарядиться полностью прошлый раз.

Если свет моргнёт ещё раз, надо либо сутки стоять на дизеле и заряжать батареи, либо рисковать переключением с возможностью не переключиться обратно. Стандартная процедура — стоять на дизеле до безопасного заряда батарей.

Ещё несколько раз свет «мигал», когда питание прерывалось на несколько секунд, без переключения на дизели.

В прошлый понедельник ситуация повторилась
Питание с двух — напомню, независимых с независимыми маршрутами — подстанций пропало на 20 минут.

И вот в этот момент вылетело два ИБП.

Это вызвало отключение четырёх серверов, которые были одновременно подключены к вылетевшим батареям. Остальным серверам повезло больше, у каждого был как минимум один ИБП.

Почему всего четыре, а не полстойки? Потому что эта стойка неполная.

ИБП при такой нагрузке вылетать не должны.

Но!

Во-первых, мы планировали плановую замену батарей в ИБП как раз в начале декабря (напоминаю, авария — уже почти середина декабря). 2 декабря мы оплатили счета за них, и они должны были приехать 3–5 декабря.

Они действительно приехали к поставщику, но коробки оказались битые.

Поставщик отказался поставлять батареи, и был на 100% прав. Если логисты побили коробку — это всегда возврат и тщательная диагностика, возможно, списание.

То есть ровно неделю мы стояли с несколькими батареями за сроком плановой замены.
Срок плановой замены подбирается с запасом. Это не так, что ровно день в день батарея умирает.

Диагностика у нас постоянная, в помещении сверяется температура (она около 18–19 градусов Цельсия), плюс мы смотрим напряжение. У самих ИБП тоже есть собственные средства диагностики, и они зажигают лампочки, если нужна замена батарей.

Лампочки не горели. Температура была нормальная. Батареи давали нормальное напряжение.

Но часть из них почему-то решила взять и умереть при разряде в понедельник в этих двух ИБП.

Понедельник
В понедельник я оказался в странной ситуации:

• Мы не понимали, что случилось. Но поддержка уже ответила клиентам наиболее вероятной версией, что в результате некоторого испорченного телефона стоило нам сильного недопонимания клиентов. Очень упрощая, клиент спросил, есть ли резервирование ИБП. Админ ответил, что нет, ни один ЦОД так не делает. Админ имел в виду ЦОДы TIER-III (T4 так делает) и резервирование 2N по мощности. ИБП должны выдерживать 2 переключения на своих батареях, и общий пул батарей не дублируется практически никогда. Смысл в том, что это именно общий пул, суммарная ёмкость. Она уже содержит резерв. Но из-за непонимания, что каждый имел в виду, клиент решил, что резервирования питания в ЦОДе нет.
• Я в это время пытался разобраться с поставщиком и достать батареи быстрее.
• Через несколько часов мы решили, что вместо расследования причин проблем с батареями, сначала надо провести все плановые замены. Поставщик не успевал с повторной поставкой, поэтому мы поехали и купили батареи в магазине как физики.
• Дальше мы ковырялись с заменами и всё поменяли.
• Ещё позже приехали батареи от поставщика.
• До вечера мы разбирались с тем, что происходит.
• Затем начислили положенные по SLA компенсации за простой тем, кто пострадал.
• В итоге мы почти не трогали обсуждения, и в публичном поле творилось не самое хорошее.

Главный мой вопрос был — а что именно случилось с батареями? Они не должны были так деградировать. Плановая замена на то и плановая профилактическая, чтобы такого не было. Если бы горели лампы «замените батарею», можно было бы рассуждать про то, что мы не так обслужили ИБП, но смысл профилактической замены — сделать всё так, чтобы эти лампы никогда не загорались.

Первая наша гипотеза, которую поддержали инженеры, — батареи стали хуже. Тут я обосновать пока не могу.

Второй вариант — частые «мигания» питания могли повредить батареи. Но вообще-то они для этого и спроектированы.

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

Непохоже, что проигрывая эту ситуацию ещё раз, мы поступили бы иначе, имея тот же набор исходных данных для решения.

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



Возвращаюсь к вопросу открытости
Если бы мы ничего никому не сказали, ситуация для нас была бы гораздо легче. Время такое, что всё, что угодно, можно свалить на блокировки, санкции и т.п. И даже подсказывать не надо, это вроде как самоочевидная причина, люди сами очень быстро так подумают.

Если бы мы сказали позже на сутки, не было бы слухов и неправильного толкования того, что сказал саппорт. Они отвечали, ещё не до конца поняв, в чём проблема. Можно было не отвечать? Спокойно. Все так делают.

С другой стороны, пострадало 4 сервера в одном из 20 ЦОДов. Но ощущение из-за нашей публичности было такое, как будто авария крупная. И вот здесь главный минус открытости — складывается впечатление, что у нас такое происходит чаще, чем обычно. Так вот, нет. Ломается всё у всех, но если про это не говорить, это незаметно.

Я всё ещё считаю, что нужно держать в курсе всегда и по имеющимся на текущий момент данным. У нас открыты чаты и комментарии везде, есть сообщество клиентов в ТГ. Да, нас больно бьют за каждую проблему, и некоторые вещи эмоционально очень хочется не рассказывать. Это цена открытости.

ruvds.com/ru-rub

Всем привет! В этом году нам исполнилось 10 лет! Не так много по меркам истории, но Вояджер за это время вон куда улетел. В этой статье будет 27 коротких интересных фактов о том, что произошло за эти годы — уверены, про многое вы даже не знали (и не могли знать).



1. У компании три дня рождения

• 18 сентября 2015 года был зарегистрирован домен ruvds.com
• 16 октября 2015 года были прописаны NS-записи и сайт впервые вышел в онлайн
• 16 декабря 2015 — первый пользователь сервиса!

Первые два мы уже отметили :) А вот с третьим можете нас поздравлять прямо сегодня в комментариях.

2. 315 500 491 секунда аптайма
Мы на связи 10,004 лет. И с каждой секундой значение растёт!

Посчитаем в наших любимых космических масштабах. Voyager-1 (самый быстрый из двух) удаляется от Солнечной системы со скоростью примерно 17 километров в секунду, то есть за время нашего аптайма на одометре «путешественника» набежало 5 365 508 347 км — не парсек и даже не световой год, но всегда надо к чему-то стремиться! Расстояние от Земли до Солнца (1 астрономическая единица) на данный момент 149 597 870,7 км, то есть за время нашей работы далёкий странник прошёл это расстояние 35,85 раз — 17 раз сгонял туда-обратно и сейчас завершает 18-й ;)

3. 1 207 572 созданных виртуальных сервера
Столько серверов было создано за всё время нашего существования на момент написания публикации. Прямо сейчас эта циферка уже выросла — актуальное значение мы выводим в футере нашего сайта:

Если бы каждый сервер был сухой рисинкой весом в 0,03 грамма, то получилось бы скромных 36,227 кг. Но если этот рис сварить (каждая рисинка станет вдвое тяжелее), то полученной массы хватило бы на 3 864 ролла Филадельфия (гугл выдаёт расход в 150 г риса на 8 штук). До задачи про зерно и шахматы ещё далеко, но опять же, есть к чему стремиться. Да и аппетит пусть нагуляется — ниже будет ещё кое-что вкусное.

4. 20 дата-центров
И было это так:

• 2016 — открыли свой ДЦ Rucloud в Королёве
• 2017 — Цюрих (Швейцария)
• 2018 — Лондон, M9 (Москва)
• 2019 — Франкфурт, Екатеринбург, Казань и Санкт-Петербург
• 2020 — Останкино (Москва), Амстердам и Новосибирск
• 2023 — Астана, Алматы, Владивосток, Измир (Турция) + Космический ЦОД RUVDS (спутник)
• 2024 — Арктический ЦОД (временный))
• 2025 — Ереван (Армения), Краснодар, Мурманск, Омск и Уфа

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

Кстати, совсем скоро — новый спутник-платформа и ЦОД в Антарктиде, stay tuned ;)



5. Суммарное потребление наших серверов — более 2 МВт·ч в сутки
Вроде совсем немного, но в то же время не так уж и мало. Гугл подсказывает интересные аналогии:

• Примерно столько же потребляет коттеджный посёлок на 60–80 частных домов среднего размера.
• Примерно столько же вырабатывало бы за день 400–600 (в зависимости от подготовки) человек на велотренажёрах.
• Можно было бы полностью зарядить ~20–34 тыс. макбуков (Pro/Air), то есть на всех сотрудников Яндекса должно хватить )

6. 8198 физических процессорных ядер
Ядра — чистый изумруд! :)

7. 128 000 Тб оперативки (ОЗУ)
Таком суммарный объём оперативки (ОЗУ) наших серверов. Мы используем надёжную серверную оперативную память DDR4 с частотой 3200 МГц и DDR5.

8. Будни поддержки за 10 лет
Мало приютить у себя каждого клиента — нужно помочь ему в том случае, если у него возникают проблема. Вот несколько цифр из будней нашей технической поддержки:

• 146 575 тикетов в хелпдеске за 10 лет
• 657 000 отправленных смс
• 63 781 принятых звонков

Что касается смс, то в основном речь про сообщения двухфакторной авторизацией — они по 92 символа. 77 — в сообщении об оплате или неоплате, которых тоже хватает. Если посчитать среднее значение в 85 символов, то получим 55 845 000 символов. По неточной информации из сети можно узнать, что в стандартном издании произведения «Война и мир» примерно 700 000 символов с пробелами, то есть за всё время на телефонах наших пользователей суммарно осело около 80 копий издания.

9. ~116 тысяч обращений в онлайн-чате
То есть примерно по 11600 в год или 31 в день. Но, конечно, в разные дни нагрузка может отличаться — например, в дни аварий (а у нас они тоже случаются) бывает нескольких сотен сообщений и до 200 звонков (и около 500 в месяц в спокойное время).

10. 361 статья в справочнике RUVDS
Заходите, читайте и мотайте на ус — там целая база знаний. Если чего-то не хватает — сообщите, добавим или напишем вместе.

11. Более 200 партнёров по партнёрской программе
Всех поимённо не помним, но спасибо каждому из них!
Процент отчислений партнёру со списаний приведённого клиента стартует с 15% и увеличивается по мере роста числа активных серверов привлечённых клиентов и общей заработанной суммы:

• от 0 активных серверов или заработанных 0 руб. – 15%
• от 30 активных серверов или заработанных 20 000 руб. – 20%
• от 60 активных серверов или заработанных 40 000 руб. – 25%

12. 75 590 799 бонусов начислили клиентам
Просто факт с такими вот цифрами
ruvds.com/ru/bonus/
ruvds.com/ru/helpcenter/bonusnaya-programma-ruvds/

13. 3 корпоративных блога
Хабр, извини, но ты у нас не один: мы также ведём блоги на VC и Pikabu. Но, положа руку на сердце, можем уверенно сказать — Хабр любим больше всего.

Несколько достижений блога RUVDS на Хабре:

• 8 лет на первом месте рейтинга среди всех компаний
• 4690 публикаций (все с положительным рейтингом), 329 новостей и 58 постов
• Рейтинга блога в 4137 единиц, абсолютный рекорд площадки

Итоги блога за год в сравнении с предыдущими годами мы традиционно подведём ближе к Новому году.

14. 5200 Хабрабургеров
Помните Хабрабургер?! Вспоминаем, и вкусовые сосочки невольно возбуждаются. По информации от нашего партнёра Burger Heroes, за всё время существования бургера было изготовлено 5200 порций или 2% от объёма продаж сети на тот момент!

Кстати, калорийность бургера была в районе 617 ккал (что в 2+ раза больше, чем у биг-мака). Суммарно имеем дело с 3 208 000 ккал. Если за марафон сжигается примерно 3000 ккал, то наших бургеров хватило бы на 1069 марафонов или на 45 131 километров — достаточно, чтобы пробежаться по экватору (и ещё бы несколько тысяч км осталось на карманные расходы).

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

15. Сварили 100 тонн пива Smart admin
«Лёгкий, светлый, ароматный эль с низким уровнем горечи и бархатным обволакивающим вкусом, который отправляет тебя на светлую сторону» — так про нашу коллаборацию с Beer Bros Brewery написано на сервисе UNTAPPD.


Но не все знают, что ещё было несколько тонн Dark admin для фанатов тёмной стороны.


И ещё был совсем уж лимитированный шотландский эль Duke Nukem, созданный в коллаборации с Ричардом Греем (Levelord) по лицензии GearBox — со вкусом копчёного бекона ;)


16. 33 часов
Про этот факт совсем мало кто знает, так как часы были выпущены совсем в небольшом количестве. Часовое производство «Русское Время» помогло нам запечатлеть в металле, стекле и коже наши воспоминания и эмоции от развёртывания нашего оборудования в Арктике.



17. 1 воздушный шар, 1 стратостат и 2 спутника
Сначала батут, потом воздушный шар, потом стратосфера и наконец-то выше облаков, космос! Один спутник был успешно запущен, все материалы и подробности можно найти на отдельном сайте или у нас в блоге.

Второй спутник полетит в космос в конце декабря, на борту которого будут крутые статьи пользователей Хабра, первый космический антивирус от Лаборатории Касперского и кое-что ещё интересное — следите за новостями.

18. 4 хакерских квеста
Шредер для денег, рояль, азот и котики, спутник — ну же, вспоминайте, как не спали вместе с нами и пытали свою удачу и смекалку. Ещё со своей инфраструктурой мы участвовали в Standoff 12 — это, кстати, был первый CTF на спутнике в мире.



Несколько ссылок, чтобы поностальгировать: раз, два, три, четыре, пять и шесть.
Количество участников квестов: 620, 2340, 177, 213 + 15 команд пентестеров общей численностью 100 человек.
Кстати, 0 — столько профессиональнов пентесторов смогли взломать спутник в рамках киберучений Standoff.

19. Провели 3 квиза
В сети бескрайнее множество информации, полезной и бесполезной. Когда знаешь какой-нибудь интересный факт, так и хочется рассказать его кому-то… или усложнить задачу — предложить угадать правильный ответ из нескольких, среди которых невольно хочется добавить каплю юмора. Ну любим мы такое!

Некоторые вопросы в них уже могли потерять актуальность, но всё равно можете попытать свою удачу и любознательность:

• Пол лимона — приуроченный к 500000-му виртуальному серверу
• Космический — 22 вопроса на тему космоса
• На все 100

20. 3 конкурса лучших статей на Хабре и Космотекст
Три раза мы проводили конкурс лучших статей на Хабре (первый, второй, третий), а совсем недавно завершили Космотекст, в рамках которого отправим в космос несколько десятков отборных статей с Хабра.


21. Три раза поддержали Технотекст
Сами мы в нём тоже участвуем и даже иногда занимаем призовые места — по оценкам других членов жюри.
Кстати, совсем скоро вроде как стартует Технотекст-8 — восьмой конкурс технических статей Хабра, который мы, забегая вперёд, в очередной раз планируем поддержать классными призами и помощью в жюри. Попытаем удачу и в этот раз!

22. Ачивки
Не стыдно достать парадную одежду со следующими медальками:

• Мировой рекорд — за прыжок из стратосферы, подробнее тут
• Разместили первый в истории сайт в космосе
• Первый в мире CTF в космосе
• «Лучший блог о системном администрировании» от Хабра в 2021 году
• Несколько побед в «Технотекстах» разных лет
• 1 патент на ПО — у нас там собственные сетевые драйверы для повышения эффективности распределения каналов связи между пользователями, драйверы сертифицированы Microsoft для Hyper-V. Есть регистрация в Федеральном реестре интеллектуальной собственности.
• Первые в России застраховали свою ответственность перед третьими лицами в AIG за несанкционированное публичное раскрытие персональных данных и корпоративной информации — это случилось ещё в 2017 году.

Также есть 4 награды от ЦОДЫ.рф:

• «Креатив года» в 2021
• «Хостер года» в 2023
• «Человек года» в 2024
• «Креатив года» в 2025

Бережно храним и планируем бороться за новые. Спасибо всем, кто нас поддерживает!

23. Среди лиц бренда RUVDS есть 2 настоящих космонавта
Вы их наверняка знаете и уже что-то читали про них:

• Михаил Корниенко — Герой России, лётчик-космонавт; пребывание в космосе — 516 дней 10 часов и 1 минута
• Александр Лазуткин — герой России, лётчик-космонавт, бортинженер орбитальной станции «МИР»; Пребывание в космосе — 184 дня 22 часа и 7 минут

24. 2 совместных игры
Совместно с ветераном игровой индустрии, дизайнером уровней культового Duke Nukem — Ричарда Грея, мы сделали две игры

• Атомный Графъ
• Спутник против мусора

Да, это далеко не Red Dead Redemption, но всем иногда хочется позалипать в каком-нибудь тайм-киллере (а на момент запуска можно было ещё и выиграть ценные призы).

25. 1 битва роботов-хоккеистов
Поучаствовали и в такой забаве :) О том, как готовили хоккеистов, рассказывали в отдельной публикации.


26. 1 регата
Иногда нужно выдернуть шнур выдавить стекло закрыть ноутбук, выключить телефон и выбраться куда-то на природу. В таком формате нам больше всего запомнилась регата, гонка парусных судов. 400 участников, 45 яхт и 5 дней гонки под парусом — травили и набивали как могли.



27. Стали членом Ассоциации участников отрасли ЦОД
Этим летом мы стали 50-ми участниками ассоциации, а что это и зачем вкратце рассказываем тут.

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

Надеемся, вам было интересно. Начинаем второй десяток — спасибо, что вы с нами!

«Лаборатория Касперского» разработала для хостинг-провайдера VPS серверов RUVDS специализированное решение Kaspersky Endpoint Security for Linux (KESL) — Space Edition, которое поможет обеспечивать защиту спутника-платформы RUVDSSat1 на протяжении всей его миссии. Программное обеспечение создано на базе технологий KESL с учётом особых требований к производительности в условиях ограниченных вычислительных ресурсов на орбите.

Спутник выступит в качестве испытательного полигона. За решение ИТ-задач в космическом аппарате отвечает отдельный микрокомпьютер Raspberry Pi Zero с частотой процессора 1GHz и 512MB оперативной памяти. «Лаборатория Касперского» адаптировала технологии KESL под данную платформу, чтобы обеспечивать защиту полезной нагрузки, которую размещает на спутнике хостинг-провайдер RUVDS.

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

Как показал наш опыт, в том числе и с предыдущим спутником, обеспечившим первый в истории хостинг сайта прямо с орбиты, космические аппараты подвергаются точно таким же рискам, как и объекты инфраструктуры или частные вычислительные устройства на Земле. В нашем новом проекте мы ещё более открыты аудитории, потому вопросы кибербезопасности занимают в нашей повестке особое место. Мы рады сотрудничеству с „Лабораторией Касперского”, уверен, совместная работа над проектом самым положительным образом скажется на обеих компаниях и поможет в разработке новых решений

подчеркнул генеральный директор RUVDS Никита Цаплин.

Защита таких аппаратов, как спутник-платформа RUVDSSat1, требует особого подхода, поскольку они обладают ограниченными вычислительными ресурсами. Возможности Kaspersky Endpoint Security для Linux позволили нам справиться с этой задачей. Наше решение учитывает специфику ПО для автономных летательных аппаратов, в том числе это касается энергопотребления. Мы будем внимательно наблюдать за результатами проекта, чтобы использовать полученный опыт для развития наших технологий. Это позволит нам эффективнее защищать устройства с небольшими вычислительными мощностями, в частности IoT-приборы

комментирует Анна Кулашова, вице-президент «Лаборатории Касперского» по развитию бизнеса в России и странах СНГ.

Количество успешных кибератак на российские организации в следующем году может увеличиться на 30-40%, а пик активности злоумышленников, вероятно, будет достигнут в Единый день голосования в конце сентября. Соответствующий прогноз сделал генеральный директор хостинг-провайдера RUVDS Никита Цаплин в ходе выступления на Открытой конференции ИСП РАН в Москве.

По нашим оценкам, общее число количество успешных кибератак на организации нашей страны вырастет на 30–40%. Скорее всего, пик будет достигнут в конце сентября, когда в стране в Единый день голосования пройдут выборы – в том числе и в Государственную Думу. Потому можно предположить, что атаки на госсектор станут самыми массовыми, и на них придётся больший процент от общего числа вредоносных активностей

подчеркнул гендиректор хостинг-провайдера VPS-серверов RUVDS Никита Цаплин.

Также в ходе своего выступления с докладом «Адаптивные методы и средства поверхностного анализа пакетов для обнаружения аномалий в зашифрованном трафике» гендиректор хостинг-провайдера отметил, что перспективы снижения геополитической напряженности не скажутся на активности злоумышленников радикальным образом – общий рост угроз продолжится.

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

С 31 декабря 2025 года некоторые услуги RUVDS станут чуть дороже. Среднее повышение составит около 7 %. Мы старались удержать цены на максимально комфортном уровне, но изменения на рынке и в налоговой сфере делают корректировку неизбежной.

Чем вызвано изменение цен

• С 1 января 2026 года НДС в России повышается с 20 % до 22 %, а порог применения льготного режима УСН снижается.
• Растут цены на коллокацию в коммерческих дата-центрах — от 15 до 35 %.
• Становятся выше затраты на комплектующие: оперативная память и другое оборудование уже подорожали в 1,5–2 раза.

Что нас ждёт в новом году
Тарифы RUVDS вырастут в среднем на 7,6 %, максимум — 11,4 %, в зависимости от конфигурации. При этом повышение не затронет тарифы «Старт», «Турбо» и «Драйв», а также аренду IPv4-адресов. Мы продолжаем держать часть расходов на себе, чтобы минимизировать рост цен для наших клиентов.

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

Как сэкономить
Кроме того, при продлении серверов на год вперёд действует скидка 30%. Чтобы воспользоваться ей, пополните баланс и создайте новый сервер или продлите текущий до 30 декабря 2025 года включительно, обязательно списав деньги с баланса личного кабинета.

Сравнение текущего и будущего тарифов «Своя конфигурация» для российских и зарубежных дата-центров (в рублях, в месяц):


Мы благодарим вас за понимание и продолжим предоставлять надёжные и качественные услуги, несмотря на изменения на рынке.

С уважением, команда RUVDS.

Вот так выглядит ЦОД в Новосибирске
В целом для коммерческих ЦОДов — правда, но есть и нюансы.

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

Это классическая проблема курицы и яйца. Коммерческий ЦОД строить там невыгодно, потому что нет клиентов, а клиентов нет, потому что нет нормальных ЦОДов.

В регионах живут в основном каптивные ЦОДы. Это когда условная налоговая или какой-нибудь гигант вроде «Норникеля» строит объект чисто под себя. Им вообще всё равно, где строить: они делают по потребности, а не по условиям. Если госзаказчику по плану нужно построить ЦОД во Владимире или Ярославле — они построят там. Им не нужно бегать по рынку и искать заказчика, у них стопроцентная загрузка своими же расчётами или данными. Производственники могут построить хоть в тундре, и вопрос окупаемости за счёт внешних арендаторов там не стоит.

А вот если ты хочешь построить коммерческий объект для сдачи стоек в аренду, то тут вступают в силу другие законы. В регионах просто нет такого объёма экономики, чтобы окупить полномасштабный ЦОД. Считается, что в регионе есть смысл начинать стройку, только если у тебя есть предзаказ («якорь») минимум на 60% мощностей. Если этого нет, то ты построишь коробку, которая будет генерировать убытки.

Но начинается всё с дешёвого электричества, конечно. Оно важнее, чем аплинки.

Кому это вообще нужно на месте?
Вот представьте: вы в условном Тундрятске или Уволжске. У вас торговый центр, все клиенты — из вашего города. И вам нужен сервер. Вы лезете в Яндекс, но на первых страницах нет местного провайдера.

Там есть московские гиганты, которые предлагают виртуалки и колокацию. И дальше вы покупаете виртуалку именно в Москве.

Реальный спрос на местное размещение есть только у узкой прослойки:

• «Сектанты» физического доступа. Условный завод железобетонных изделий в Тундрятске. Им нужно хранить фото форм отливки или локальную базу. Владелец рассуждает так: «Не хочу Москву, не хочу облака. Хочу, чтобы сервер стоял здесь и чтобы мой админ Вася, которому я доверяю, мог сесть в машину, доехать и лично нажать кнопку». Они там так мыслят. Если сервер можно пощупать — он свой. Если нельзя — он чей-то. Ну и вторая особенность: если что-то пойдёт не так, то хотелось бы приехать и забрать его руками, а не пытаться понять, что там в Москве. Вообще колокация в Москве часто вызывает нездоровые ассоциации с дальними командировками и затратами. Плюс в вопросах бизнеса москвичи стереотипно считаются скользковатыми, и лучше уж договариваться с местными.
• Тяжёлый контент и спецзадачи. Медицинские клиники, обрабатывающие снимки МРТ (гонять терабайты в Москву и обратно дорого и долго), или игровые сервера, где лаг критичен.

То есть спрос как бы есть, но по факту он очень мал. Часто выгоднее и проще работать именно с Москвой.

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

Но есть и совершенно особенные местные детали.

Уфимская петля
Готовьтесь к абсурду с маршрутизацией. Вот живой пример из Уфы. Мы разместились в дата-центре крупного местного провайдера. Казалось бы, мы в Уфе, клиент — сосед через дорогу, он подключён к домашнему Интернету того же провайдера. Пинг должен быть нулевым, трафик не должен покидать пределов города.

В реальности местные операторы пытаются защитить свою сеть. Денег на собственных безопасников и дорогое железо для фильтрации у них нет. Они идут по пути наименьшего сопротивления — покупают готовые решения: StormWall, DDoS-Guard, Qrator. А узлы очистки у этих ребят стоят где? Правильно, в Москве, на М9. Или ещё дальше.

Получается дикая схема. Клиент из Уфы стучится на сервер в Уфе. Его пакет летит в Москву, там проходит очистку и только потом возвращается обратно в Уфу.

Мы делаем петлю через полстраны.

Пишем им: «Ребята, мы свои, мы стоим у вас в стойке, мы белые и пушистые. Примите нас за своих, отключите фильтрацию StormWall для нашего трафика, пустите напрямую! На все инциденты мы отреагируем сами».

И вот это согласование — просто чтобы нас признали своими внутри сети — может висеть неделями.

Уфа — просто свежий пример, такое случается и в других городах.

Как искать ЦОД — это отдельная боль
Пару раз мы не находили нужных дата-центров.

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

У нас была показательная история в Омске. Мы искали площадку, перерыли всё — глухо. В итоге пошли по рекомендации нашего вышестоящего оператора связи. Они сказали: «Вот этот оператор надёжный, мы с ним 20 лет работаем, и он ни разу не подвёл». Мы приехали — там всё скромно, без лоска, скорее это узловая операторская, а не коммерческий ЦОД. Никаких красивых сертификатов Tier III на стене. Но нам важнее рекомендация партнёра, чем бумажка. Сертификат можно купить, а вот готовность местной техподдержки вовремя воткнуть KVM в сервер посреди ночи — это бесценно. Мы встали туда.

Написали про это статью на Хабр. И тут в комментарии приходят представители другого омского ЦОДа и обиженно пишут: «А чего вы нас не рассмотрели? У нас же настоящий ЦОД!» Мы позвонили, поинтересовались что и как. Очевидно, что переставлять уже не было смысла, и рекомендация оператора при этом не менялась. Они: «Ну надо было связаться, мы организовали бы вам канал, подключили провайдера...»

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



Потом, правда, пришёл ещё человек и сказал, что первый — не от дата-центра, и вообще история мутная. Мы до сих пор не понимаем, что происходит.

Опять же случай неединичный.

Для поиска дата-центров есть даже специальные риэлторы.

Брокеры: риэлторы для ЦОДов
Из-за того, что самому найти площадку сложно (или нет мест), появились брокеры. Это как риэлторы, только ищут не квартиру, а стойку.

Зачем они нужны, если можно позвонить напрямую?

Сейчас в Центральной России — дефицит мест. Вы можете прийти в ЦОД с улицы, и вам скажут: «Мест нет». И хоть ты тресни! А у брокера там могут быть выкупленные огороженные зоны или зарезервированные стойки, которые он держит под своих клиентов. Он знает внутреннюю кухню: кто съезжает, где что освобождается. Вам найдут.

У них партнёрские цены, которые сильно ниже прайса с улицы.

Мы искали точку в Мурманске. Оказалось, что на всём Кольском полуострове коммерческих ЦОДов, по сути, нет. Я писал напрямую в Ростелеком — они мне отвечали месяца два или три. Брокер к ним тоже постучался. В итоге, когда Ростелеком проснулся, у них лежало две заявки — от меня и от брокера. Бардак, конечно, дозвониться невозможно, но брокер хотя бы матерился на них вместе со мной — уже психологическая поддержка.

Как обычно выглядит региональный дата-центр
Это часто не отдельное здание, а полусерверная на территории какого-нибудь завода или офисного центра. И тут есть два нюанса.

Типичный региональный ЦОД


А вот, например, очень приличный ЦОД в Казани


В Москве попасть в хороший ЦОД — целая спецоперация. Это режимные объекты, бункеры, бюрократия, пропускная система, как на космодроме. В регионах всё проще, «по-людски». Проще завезти оборудование, проще попасть инженеру. Меньше формализма.

Вторая особенность — в Москве найти толкового админа сложно, а в регионе — почти невозможно. Это как с Макдоналдсом: в Москве логистика и стандарты отлажены, а открой точку в Уволжске — тебе поставщик картошку плохую привёз, кассир запил и не вышел и т. д.

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

Но при этом по факту аптайм в регионах часто бывает лучше, чем в столицах!

Из-за низкой плотности!

В крупном московском ЦОДе типа IXcellerate сидит куча клиентов. Там и банки, и энтерпрайз, и хостеры. А хостер — это агрегатор кучи мелких клиентов и, будем честны, кучи всяких чудаков. Когда в одном месте собирается такая толпа, постоянно случается какая-то ерунда: кто-то канал положил DDoS-атакой, кто-то питание дёрнул, кто-то настройки перепутал. Чаще всего один проблемный клиент с дидосом создаёт головную боль всем. В региональных ЦОДах плотность низкая. Стойки стоят полупустыми, каналы не забиты под завязку. Соседей мало, никто локтями не толкается. И атак меньше, и аварий по вине соседа почти не бывает.

Итог
Мы продолжаем открывать региональные ЦОДы под VDS, у нас площадки — по всей стране. Есть Казань, Екатеринбург, Новосибирск, Краснодар, Омск, Мурманск, Уфа. Москва и Петербург тоже есть.

Это местами очень странно, местами — тяжело, но в целом работает. Рынок дикий: чуть улучшить условия и прозрачность не помешало бы всем.

ruvds.com/ru-rub