Обновить
128K+

Хостинг

Виртуальный, Dedicated, Colocation

144,84
Рейтинг
Сначала показывать
Порог рейтинга

Память VDS. Что стоит за строкой «8 ГБ» в тарифе
Число в тарифе отвечает на один вопрос: сколько памяти увидит гостевая система. Зарезервирован ли объем физически, может ли гипервизор забрать страницы обратно и что будет при пике соседей, оттуда не следует.

Три слова, которые каждый понимает по своему. Dedicated обычно означает объем, постоянно доступный машине по условиям тарифа. Слово «постоянно» стоит уточнить: резервируется ли память на хосте и может ли ballooning ее уменьшить. В burstable часть доступна всегда, остальное при свободном ресурсе узла. Shared значит, что резервирования нет. Даже при dedicated провайдер может разрешать swap на хосте, поэтому гарантия в договоре важнее названия модели.

Ballooning и overcommit. Ballooning работает через драйвер внутри гостя. По команде хоста он занимает страницы, ядро гостя освобождает кеш или уходит в свой swap, а высвобожденную память гипервизор отдает другим машинам. Пока баллон надут, приложения работают с меньшим объемом, чем в тарифе. Overcommit это когда сумма лимитов больше физической RAM узла. Умеренная переподписка работает годами, пока гости используют часть лимитов. Пример: после резерва под системные процессы на узле осталось 120 ГБ, машинам назначено 180. При суммарном рабочем наборе 80 ГБ никто ничего не заметит. При 140 придется забирать страницы через ballooning или уходить в swap хоста. Overselling это тот же overcommit, но с недостаточным запасом: разница не в технологии, а в коэффициенте.

Что видно изнутри, а что нет. Сразу о границе: коэффициент переподписки из гостевой системы не определяется никак, эти данные есть только у провайдера. Изнутри ловится давление на память и его совпадение с замедлением сервиса.

free -m && grep -E "MemAvailable|SwapFree" /proc/meminfo
vmstat -y 1 10
procs ---swap-- -----io---- ---cpu---
 r  b   si   so    bi    bo  us sy id wa st
 1  2  184  412  1240   980  22  6 61 10  1

Смотреть надо на MemAvailable, а не на free: файловый кеш при нужде освобождается. Ненулевые si и so в нескольких интервалах подряд это обмен сейчас, а не след прошлого пика.

cat /proc/pressure/memory
some avg10=14.82 avg60=9.31 avg300=3.07 total=8123441
full avg10=6.55 avg60=4.02 avg300=1.18 total=3910228

PSI это доля времени, потерянного задачами из за нехватки памяти. Строка some означает, что простаивала хотя бы одна задача, full что вставала вся работа. Четырнадцать процентов в avg10 при выросшем времени ответа это разговор, а не шум.

journalctl -k -g "oom|Killed process"

Если процесс убило ядро гостя, запись будет здесь. Отсутствие записи при остановившейся машине это отдельный сюжет: OOM хоста может завершить процесс самой машины, и в журнале гостя причины не будет.

Признаки, которые стоит собрать вместе. Задержка растет в одни и те же часы при сопоставимой нагрузке. Устойчивые si и so без изменения профиля приложения. PSI растет синхронно с замедлением. Машина останавливается без записи об OOM у себя. Один признак ничего не доказывает, три совпавших уже повод писать в поддержку с временем эпизодов и метриками.

Что спросить до заказа. Какой объем зарезервирован, а не просто виден. Допускается ли ballooning и до какого минимума. Разрешен ли swap на хосте для памяти машин. Для burstable отдельно: гарантированная часть и условия доступа к остальному.

Тип гипервизора говорит об архитектуре, а не о гарантиях: overcommit поддерживают и KVM, и VMware, и Xen. SLA обычно описывает доступность и компенсацию за простой, но не производительность.

Теги:
+5
Комментарии1

Дайджест Рег.облака за июль

В июле запустили третий этап Free Tier — бесплатный облачный сервер, ресурсов которого хватает уже на бизнес-проекты. Плюс упростили работу с ispmanager, открыли линейку «Стандартные» в двух регионах, добавили готовые образы в аттестованный контур ФЗ-152 и поделились исследованием о спросе на облако и GPU. Ниже — главное.

Запустили третий этап Free Tier — теперь и для бизнес-нагрузок

Расширили бесплатный облачный сервер до конфигурации, которой хватает для корпоративных порталов, крупных интернет-магазинов и ресурсоемких сервисов. На третьем этапе Free Tier дает выделенный облачный сервер бесплатно на два месяца: два виртуальных ядра, 4 ГБ оперативной памяти и 40 ГБ NVMe. Сервер подходит для проектов на «1С-Битрикс», переноса крупных сайтов с виртуального хостинга, баз данных и подготовки CI/CD-сред.

Подробности — на странице программы.

Исследование: спрос смещается к облаку, bare metal и GPU

Посмотрели, как за два года изменился спрос бизнеса на инфраструктуру. В публичном облаке акцент сместился с запуска проектов на резервирование: снапшоты используют 35,2% компаний малого бизнеса и 37% среднего. В dedicated и bare metal стало больше крупных клиентов — число компаний с расходами выше 500 тыс. руб. в месяц выросло более чем вдвое.

Особенно вырос спрос на GPU: за январь–июнь 2026 г. потребление прибавило 507% год к году. Чаще всего берут NVIDIA A4000 — у 63% компаний, и приходят за ускорителями уже не только ИТ, но и электронная коммерция, производство, логистика и финансы.

Все цифры — в исследовании.

Управление ispmanager для выделенных серверов в личном кабинете Рег.облака

Теперь панель ispmanager для выделенных серверов можно заказать и настроить прямо в личном кабинете Рег.облака. Если панель уже подключена, в интерфейсе ЛК виден блок с доступами и ссылкой на саму панель на сервере.

Открыли линейку «Стандартные» в Москве-1 и Санкт-Петербурге-1

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

Готовые образы GitLab, GitLab Runner, Nextcloud и Portainer в регионе Москва ФЗ-152

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

Разобрали свои продукты в статьях

В июле вышли два продуктовых обзора на Хабре — если пропустили, читайте:

Желаем всем продуктивного месяца и спасибо, что следите за обновлениями Рег.облака!

Теги:
+4
Комментарии1

Как проверить VDS до покупки: ядра, память, диск?
Слово VDS не закреплено ни за одной технологией. У одного это машина KVM, у другого контейнер, у третьего просто тариф подороже с пометкой dedicated. За одинаковой строкой характеристик стоят разные модели распределения ресурсов, и утренний тест дает результат, который вечером не повторится.

Что стоит выяснить до тестов? KVM запускает гостя с собственным ядром на аппаратной виртуализации, OpenVZ и LXC делят ядро хоста. Распространенное заблуждение: KVM якобы исключает оверкоммит. Не исключает, провайдер назначает машинам больше vCPU и памяти, чем есть на хосте. Отсюда вопросы к тарифу. Закреплены ли vCPU за физическими процессорами. Зарезервирована ли память. Есть ли лимит IOPS и что при его превышении. Слова dedicated, isolated и NVMe без этих ответов не значат ничего.

Ядра. Под dedicated понимают физическое ядро, закрепленное за машиной. Pinning эксклюзивности не дает: на тот же процессор оператор может посадить чужие vCPU. Проверяется это наблюдением.

mpstat -P ALL 1 60

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

cat /sys/fs/cgroup/cpu.max /sys/fs/cgroup/cpu.stat
200000 100000
nr_throttled 1843
throttled_usec 21904331

Ненулевой nr_throttled означает, что режет лимит, а не сосед. В виртуальной машине таких значений не будет. Дальше sysbench в один поток и на всех ядрах, одна версия утилиты и один cpu-max-prime на кандидатах.

sysbench cpu --threads=1 --cpu-max-prime=20000 --time=60 run
sysbench cpu --threads=$(nproc) --cpu-max-prime=20000 --time=60 run

Строгого удвоения при удвоении потоков не будет, мешают кеш и шина памяти. Настораживает обратное: многопоточный результат равен однопоточному, а mpstat показывает steal.

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

free -m && swapon --show
stress-ng --vm 1 --vm-bytes 70% --vm-keep --timeout 10m --metrics-brief

Тест гоняйте на пустой машине и параллельно смотрите vmstat. Использование swap само по себе ни о чем не говорит, оно зависит от настроек гостя. Тревожат устойчивые si и so при умеренной нагрузке и падение MemAvailable. Если процесс исчез раньше срока, ответ в журнале ядра.

journalctl -k --since "-15 min" | grep -Ei "oom-kill|killed process"

Диск. Лимит в 20000 IOPS без размера блока, соотношения чтения и записи и глубины очереди это просто число. Те же 20000 при iodepth 32 ничего не обещают при iodepth 1, а именно так работает приложение, ждущее ответа на запрос. Файл сначала заполняют целиком, иначе чтение из пустых областей завысит результат.

fio --name=randrw --filename=/var/tmp/fio.test --size=4G \
    --rw=randrw --rwmixread=70 --bs=4k --direct=1 --ioengine=libaio \
    --iodepth=1 --time_based --runtime=120 --refill_buffers=1 \
    --group_reporting --percentile_list=50:95:99:99.9

Затем тот же вызов с iodepth 32 и проверка в разделе IO depths, достигнута ли глубина. Сохраняйте IOPS и процентили clat, а не среднее. Один прогон шумного соседа не покажет, нужны три в разные часы. Растущий p99 при стабильной медиане это и есть нестабильность.

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

Универсального первого места нет. Есть тариф, проходящий ваши пороги трижды подряд в разное время суток.

Теги:
+5
Комментарии0

Облако для продакшена. Что показывают steal, await и реальная полоса?
Два провайдера, одинаковая строка в тарифе: 4 vCPU, 8 ГБ, 100 ГБ SSD, гигабит. Цена расходится на 15 процентов, и непонятно почему. Через неделю тестов выясняется, что p99 отличается в разы. Тариф описывает то, что выделено виртуально. Что происходит в железе, туда не попадает.

Почему синтетика не отвечает на вопрос? Geekbench и sysbench меряют потолок за короткий тест. Продакшен работает иначе: нагрузка неровная, соседи по ноде непредсказуемы. Провайдеры делают оверкоммит, и пока суммарная нагрузка умеренная, все хорошо. Стоит нескольким машинам дать всплеск разом, растет steal, удлиняется дисковая очередь, канал упирается в шейпер. Короткий тест может не попасть в это окно. Нужно от получаса нагрузки, а на суточные паттерны от 24 часов.

CPU steal. Steal это доля времени, когда vCPU готов работать, но гипервизор не дает ему физическое ядро. Приложение получает задержку без видимой причины: процессор загружен, работа не идет.

vmstat 1 30
procs -----------memory---------- ---cpu---
 r  b   swpd   free   buff  cache  us sy id wa st
 2  0      0 512344  81920 210488  31  4 58  1  6

Колонка st справа. Шесть процентов несколько строк подряд это не шум. Разбивку по ядрам дает mpstat -P ALL 1 10, длинный срез пишут в файл через sar -u 1 3600 и сравнивают часы между собой.

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

Для транскодирования и компиляции steal переводится во время выполнения почти линейно. Для API и запросов к базе иначе: медиана держится, а p99 растет, потому что в моменты steal запросы копятся в очереди. Отдельная история это всплески до 20 процентов на пару секунд при спокойном фоне. Такой скачок опаснее ровного высокого steal, он тянет каскад таймаутов.

Диск. Публикуемые IOPS измерены в идеальных условиях и под смешанной нагрузкой мало о чем говорят. Мониторинг запускают параллельно с тестом.

iostat -xz 1 10

В выводе важны два числа: await это время запроса вместе с ожиданием в очереди, avgqu-sz это глубина очереди. Растет второе, следом первое. Профиль OLTP проверяют так:

fio --name=rand4k --rw=randrw --rwmixread=70 --bs=4k --direct=1 \
    --numjobs=4 --iodepth=32 --size=4G --runtime=60 \
    --time_based --ioengine=libaio --group_reporting

Флаг direct обязателен, без него тест уедет в страничный кеш и покажет память вместо диска. В отчете смотрите iops и clat p99, именно второе объясняет хвосты запросов. Ориентир для средней базы это 5000 IOPS на чтении 4К при await ниже 2 мс, для нагруженной 20000 при await ниже миллисекунды.

Очередь выше восьми под OLTP это первый признак насыщения. Загрузка под 100 процентов для SSD не приговор, тревожно когда вместе с ней растет await. У дисков с лимитом IOPS порог срабатывает раньше насыщения железа, и покажет это именно await.

Сеть. Заявленный гигабит это верхний предел, а не гарантия. Шейпинг под нагрузкой в документации обычно не описан.

iperf3 -c 10.0.0.5 -t 60 -P 4
mtr --report --report-cycles 100 10.0.0.5

Четыре потока нужны потому, что один упирается в размер окна и RTT, а не в канал. Минута нужна, чтобы поймать burst лимит: полная полоса первые пятнадцать секунд и просадка дальше это он. Потери на одном промежуточном хопе при чистом трафике дальше это деприоритизация ICMP роутером. Потери подряд на нескольких хопах уже другое.

Проверьте MTU. Overlay сети добавляют заголовок к каждому пакету, 1500 превращаются в 1450, а пакеты с флагом DF молча теряются.

ping -M do -s 1472 10.0.0.5

Порядок проверки. Срез в покое сразу после деплоя, он же точка отсчета. Затем steal под боевой нагрузкой. Дальше fio с профилем приложения и iostat в соседнем терминале. Потом сеть. И наблюдение сутки или трое, иначе суточный паттерн конкуренции пройдет мимо.

Одинаковые характеристики не означают одинаковую производительность. Steal, await и реальная полоса измеряются за несколько часов.

Теги:
+6
Комментарии0

Доброго. Не прошло и года, как я писал статью о mail.ru https://habr.com/ru/posts/940422/ и вот новая. Назвал бы я это фразой "Очередные проделки mail.ru или агрессивное удержание клиентов".

Итак к сути. Достаточно давно к mail.ru привязан мой домен с бесплатной услугой "Почта для домена" от mail.ru. Изначально, к слову, на бесплатном тарифе можно было использовать неограниченное (во всяком случае точно больше 5) почтовых ящиков. Несколько лет назад лимит ящиков на бесплатном тарифе уменьшили до 5. Уменьшил, и так это всё работало у меня до 29.06.2026 примерно до 15:00 мск. Кстати, почтой пользуюсь исключительно через почтового клиента по протоколам pop3/smtp. Ну и сразу напишу, что какой бы то ни было ощутимой нагрузки на сервера не создаю, почтой пользуюсь исключительно я и только я, с одного и того же компьютера и никто другой. Периодичность отправки/получения со всех 5 ящиков примерно 1-2 письма в день, но нередко бывают дни, даже несколько дней с полным отсутствием приёмом/отправкой писем по электронке. Последнее пишу, чтобы было представление о том, создаю ли я вообще какую-либо нагрузку на почтовые сервера.

И, примерно 29.06.2026 ~15:00 мск. в логах почт. клиента появились записи:

29.06.2026, 15:00:00: ******-ERR Net dostupa na vashem tarife. Skachaite prilozhenie VK WorkSpace

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

Самым логичным, в моей ситуации было решение - уйти на сторонний почтовый хостинг. Платный, кстати.Сказано - сделано. В админке аккаунта mail.ru домен был удалён, однако mail.ru написал, что, дескать они его удалят окончательно только через 14 дней.

Тем не менее, начал перепривязывать свой домен для стороннего почтового хостинга, а именно обновил записи DNS домена в частности MX, TXT записи.

Примерно менее чем через час, я уже мог отправлять письма с почтовых адресов своего домена кому бы то ни было, НО вот с получением почты возникли нюансы, а именно: Я могу получать почту со (!)всех почтовых доменов, (!)КРОМЕ почтовых доменов mail.ru - @mail.ru, @inbox.ru, @bk.ru, @list.ru. Этим, кстати, исключается вариант неправильной настройки DNS записей домена, иначе я бы не смог получать почту вообще от кого бы то ни было.

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

Разумеется за это время было написано как обращение к платному хостеру почтового сервера, так и в тех поддержку mail.ru. На последних (mail.ru), по печальному предыдущему опыту я не особо рассчитывал, что практически и оправдало в негативном смысле мои предположения - сразу после обращения от mail.ru получил автоматический ответ с присвоением номера заявки и что они обязательно ответят не более чем через 10 часов. На данный момента с изначального момента обращения прошло более 50 часов, ничего более от них не получил!

Тех. поддержка платного почтового хостинга несколько раз отвечали, сейчас вопрос находится до сих пор в работе, но субъективно это не их вопрос и к ним у меня вопросов нет, ибо с не mail.ru адресов почта доходит без проблем. Более того, как док-во того, что проблема в mail.ru - если я отправляю письмо с одного из @mail.ru почт.серверов на ранее существующий адрес своего домена, когда я хостился в mail.ru - письмо просто не доходит, а если на не существующий адрес - получаю письмо-автоответ, "Ошибка 550 User Not Found", что говорит о том, что сервера mail.ru не обновили информацию о домене.

Теги:
Всего голосов 3: ↑3 и ↓0+5
Комментарии12

Обновили ядро Linux на всех Ryzen-серверах в Москве

В копилку стабильности — и с конкретным обновлением под капотом.

Во время работы с высокопроизводительными серверами на Ryzen 7950X нашли причину редких зависаний нод. На старом ядре Ubuntu 22.04 эти процессоры могли работать нестабильно.

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

Чтобы устранить проблему, обновили ОС и ядро на всех Ryzen-серверах в московской локации.

Переезд выполнили поэтапно: сначала подняли резервные серверы, перенесли на них проекты и только потом приступили к обновлению основных хостов. Поэтому пользователи не столкнулись с простоем.

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

Если вам нужны мощные серверы в Москве, есть еще одна новость — расширили парк Ryzen 7950X, чтобы было больше доступных конфигураций под ваши проекты.

Теги:
Всего голосов 13: ↑13 и ↓0+21
Комментарии0

▶️ История USmall — хайлоад изнутри

6+ млн товаров, 130 ритейлеров и до 70 млн запросов во время распродаж. Мигрировали USmall в наше облако и записали видеокейс о том, как устроена инфраструктура такого проекта.

Из любопытного:

1️⃣ 130 площадок — 130 изолированных контуров. На каждую свой репозиторий и Docker-образ. Релизы независимы, все изменения изолированы.

2️⃣ Свой механизм иерархических подов. В основе паттерн одноразовых подов — каждый выполняет один цикл и завершается. Поверх него команда построила иерархию, где родительский под запускает дочерние. Так обходят ограничение Python по пропускной способности одного воркера и обрабатывают задачи параллельно.

3️⃣ Выделенный сервер под оркестратор. Когда Airflow потребовалась отдельная конфигурация, под него собрали сервер на двух 32-ядерных процессорах и перенесли без простоя.

4️⃣ AI прямо в Kubernetes-кластере. В тестовом режиме крутится нейросеть, которая ускоряет подключение новых магазинов.

Все это команда ведет сама — новые ноды добавляет за пару минут через панель, без отдельных DevOps-инженеров. А инфраструктура у нас вышла на 35% дешевле прежнего провайдера — при том же объеме.

В видео Станислав, руководитель Python-разработки USmall, рассказывает про архитектуру и почему выбрали наше облако.

Смотреть видеокейс на ютубе, рутубе и в вк.

Или читать подробный разбор на сайте →

Теги:
Всего голосов 10: ↑10 и ↓0+17
Комментарии2

Тестируем 8 серверов в одном шасси

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

В новом видео Влад Олейник, ведущий инженер ЦОД, рассказал про 3-х юнитовый Microcloud компании Supermicro 3015MR с приставкой H8TNR.

В одном 3U-шасси умещается 8 полноценных серверов вместо классической схемы 1 сервер = 1 юнит. Все ноды изолированы друг от друга, а общими остаются только питание и охлаждение.

Универсальное ли это решение? Нет — поэтому покажем, где такая сборка особенно полезна:

1️⃣ 1С (SQL + App). Производительность 1С часто упирается в частоту процессора, а десктопные Ryzen как раз обеспечивают 5+ ГГц.

2️⃣ Frontend-сборка. На высокочастотных процессорах сборка может идти в 1,5–2 раза быстрее, чем на многих серверных Xeon.

3️⃣ Build-фермы. Разные типы лезвий можно подбирать под задачи CI/CD. Конфигурации с десктопными AMD-процессорами ускоряют этапы сборки, требующие высокой однопоточной производительности.

Посмотреть видео можно на ютубе, рутубе и в вк.

Теги:
Всего голосов 11: ↑11 и ↓0+18
Комментарии0

nLighten без предупреждения отключил оборудование MIRhosting в Европе

UPD0: возможно причина в этом https://habr.com/ru/articles/1040364/

UPD1: Так же возможно ситуация затронула следующие хостинги:
THE.Hosting
UFO.Hosting
Alexhost.com
Vdsina.com
Hip.hosting
Datacheap.ru
ihc.ru


Оператор дата-центров nLighten в одностороннем порядке и без уведомления остановил работу серверов MIRhosting в Нидерландах и Германии. В MIRhosting назвали действия поставщика абсолютно неприемлемыми.

Что делается сейчас:

  • MIRhosting привлекает юристов для выяснения деталей;

  • Идутся поиски альтернативных площадок для размещения инфраструктуры;

  • Инженеры пытаются восстановить доступ к серверам для спасения данных;

  • Готовятся варианты экстренного переезда для клиентов.

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

Материал основан исключительно на данных из открытых источников. Автор публикации не гарантирует достоверность предоставленных сведений и не несёт ответственности за их точность.

Теги:
Всего голосов 11: ↑11 и ↓0+15
Комментарии24

Почему Москве нужны новые дата-центры?

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

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

Облачные сервисы хороши тем, что пользователю не приходится задумываться, где находятся серверы — в Москве, Сибири или даже за границей. Грамотная организация позволяет бесшовно использовать сервисы в любой локации. Но провайдеру как раз приходится заботиться о том, чтобы дата-центры обладали нужной скоростью доступа и низким пингом, имелась возможность быстро переключиться на другие сервисы при инцидентах в текущем. Кроме того, для некоторых задач важны Edge Computing, то есть технологии, обеспечивающие вычисления в ближайших ЦОДах (для минимальной задержки сигнала).

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

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

Дефицит электроэнергии — не российская особенность, а тренд для всех развитых стран мира. В частности, в США из-за массового строительства дата-центров под ИИ планируется даже возрождение АЭС, которые смогут дать постоянные мощности по приемлемым ценам (СЭС ночью не работают, ВЭС зависят от ветра). Ресурс Servernews отмечает, что такие крупные компании, как Microsoft, SoftBank и SpaceX (недавно слилась с ИИ-компанией xAI), собираются использовать газовые генераторы, а OpenAI под проекты Oracle закупает топливные элементы.

Надеемся, что и российские регуляторы не останутся в стороне и помогут решить общемировую проблему.

Теги:
Всего голосов 15: ↑15 и ↓0+29
Комментарии0

The.Hosting — всё.

Сегодня The.Hosting разослал юзерам такое сообщение:

IMPORTANT: Notice of Service Discontinuation and Account Closure

Dear Customer,

We are writing to inform you that due to unforeseen and unavoidable force majeure circumstances, THE.Hosting is forced to permanently discontinue all its operational services and wind down its activities.

As a result, our platform, support channels, and all associated services will be closed in the coming days.

What this means for you:

New Orders & Renewals: All active forms of registration, ordering, and renewals have been disabled. No new services can be purchased.

Data & Accounts: If you have any active data, configurations, or account details stored within our systems, we urgently advise you to retrieve and back up your information immediately.

Final Termination: Once the wind-down process is completed, all accounts and data will be permanently deleted from our systems.

We deeply regret that we are forced to take this step and understand the inconvenience this causes. We want to thank you sincerely for your partnership and trust in THE.Hosting over the past period.

Sincerely,The Management of THE.Hosting


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

Проблемы у The.Hosting начались около двух недель назад, через несколько дней стало известно об изъятии серверов в Нидерландах, теперь история подошла к закономерному финалу.

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии1

Седьмая локация для облачных серверов

Теперь вы можете развернуть сервер в Нью-Йорке. Хороший вариант, если важна низкая задержка для пользователей в Северной Америке или вы хотите распределить инфраструктуру между США и Европой.

Физически дата-центр находится в Буффало, штат Нью-Йорк. Мы подключили локацию к опорно-магистральной сети, чтобы обеспечить стабильное управление и качественное соединение с инфраструктурой в других локациях.

Есть фиксированные и произвольные конфиги. Минималка 1 CPU, 1 ГБ RAM и 15 ГБ диска.

Уже доступно в панели, проверяйте →

Теги:
Всего голосов 11: ↑11 и ↓0+16
Комментарии0

От зоопарка и самописных скриптов к единой экосистеме — 3 кейса автоматизации хостинга

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

Промышленная платформа вместо самописных скриптов

Управление инфраструктурой у VPS.one строилось на разрозненных решениях — где‑то через интерфейс Proxmox, где‑то через CLI и собственные скрипты. Самописный биллинг плохо поддерживал оплату по дням, работу с несколькими платежными системами и валютами, нормальный учет периода действия услуг, автопродление и существовал отдельно от тикет-системы.

Решение: внедрение связки VMmanager + BILLmanager для централизованного управления.

Итоги: выдача VPS занимает менее минуты, доля ручных операций сократилась на 30-40%, появилась возможность быстро запускать и тестировать новые тарифы, наличие стандартизированной платформы позволило уверенно планировать запуск новых локаций и услуг.

👉 Читать целиком

От сложных интеграций к полному контролю

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

Решение: переход на экосистему ISPsystem — BILLmanager, VMmanager и DCImanager.

Итоги: время подготовки сервера к работе сократилось до 15 минут, нововведения в продуктах ISPsystem напрямую влияют на улучшение сервиса компании, позволяя быстрее реагировать на запросы рынка, простота запуска тарифов и надежности инфраструктуры позволили выйти на стабильный поток новых клиентов.

👉 Читать целиком

Построение централизованной платформы управления инфраструктурой

Инфраструктура 4VPS управлялась с помощью набора разрозненных open source решений и самописных скриптов. Ручное управление серверами и сложная интеграция инструментов не позволяли быстро наращивать инфраструктуру в соответствии с растущим спросом. Трудоемкие процессы развертывания услуг и их привязки к биллингу увеличивали затраты, время отклика и риск человеческих ошибок, что напрямую угрожало соблюдению SLA.

Решение: Интеграция VMmanager и DCImanager через единый API с собственной биллинг-системой, системами мониторинга и защиты от DDoS-атак

Итоги: автоматизация 70% процессов выдачи серверов, повышение скорости оказания услуг, увеличение парка до 27 000+ VPS, обеспечение 99.9% отказоустойчивости инфраструктуры

👉 Читать целиком

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

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Ближайшие события

Ставим все точки над ai в последних релизах по AI-агентам

1️⃣ MCP-сервер стал ближе к агентам

Теперь можно обновлять подключение к MCP-серверу, если на его стороне появились новые методы.

Пример: вы добавили новый метод для работы с API или базой → его можно подтянуть к агенту без пересоздания.

Кстати, теперь выбрать существующий MCP-сервер или завести новый можно сразу при создании агента.

2️⃣ Гибкая настройка уведомлений

Информацию о статусе агентов (например, о лимите токенов) вы можете получать не только в Телеграме, но и по почте. Также появилась возможность отключать уведомления.

3️⃣ TimewebGPT теперь в контексте

Ассистент в панели быстро ответит на базовые вопросы без обращения в поддержку:

➖ Подсказки по балансу и статусу отложенных платежей
➖ Список подключенных и доступных для заказа продуктов

На неделе выкатим еще больше обновлений — держите руку на пульсе 👀

Настроить MCP-сервер и уведомления о токенах →

Теги:
Всего голосов 9: ↑9 и ↓0+13
Комментарии0

Что случилось с т2 мобайл и мегафон? Как они выделились?

Короче, еще около месяца назад мегафон усилил фильтрацию, но, правды ради, да, обычный tcp vless+reality+vision перестал катить, нужно было либо на xhttp пересаживаться, либо же фрагментацию накинуть к тсп-шнику.

Вот на днях Т2 решили выпендриться, теперь и для них не хватает классического tcp vless+reality, но в чем дело? Видел не единожды конфиги на WS, окей, настроил WS, все один в один по настройкам. Ну казалось-бы, там и делать нечего, вот и т2 обошелся, а нет..

Структура конфига один в один соответствует структуре того, с которого списывалось, но, не работает все равно, в чем дело-то? Неужели белый айпи от вк т2 будет блокать, а айпи от яндекса(чужой конфиг, тот что работает) - пропустит спокойненько?

Или быть может есть какие-то "закадровые" настройки с которыми следует поиграться?

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии1

Новый режим для ваших приложений ⚡️

Раньше можно было запускать только статику (SSG) и одностраничные приложения (SPA). К ним добавился и серверный рендеринг (SSR).

SSR — это когда страница собирается на сервере и сразу приходит пользователю готовой. Например, в интернет-магазине вы сразу увидите товары и цены без пустого экрана и долгой загрузки.

Что дает этот режим:

  • +1 к гибкости разработки. В приложении можно использовать серверную логику, авторизацию и собственные API-обработчики.

  • +1 к SEO. Страницы рендерятся на сервере → лучше индексируются и быстрее попадают в выдачу.

  • +1 к простоте архитектуры. Не нужно создавать отдельный бэкенд, ведь часть логики можно держать в SSR.

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

Минимальный конфиг: от 510 ₽/мес с 1 CPU и 1 ГБ RAM

☝🏻 После деплоя режим изменить нельзя. Для других настроек создайте новое приложение.

Запустить SSR на своем проекте →

Теги:
Всего голосов 9: ↑9 и ↓0+13
Комментарии0

Один из самых популярных сетевых стеков в мире — теперь в нашем маркетплейсе 🌍

Добавили FreeBSD сразу в трех версиях:

  1. FreeBSD 14 — стабильная база для продакшена

  2. FreeBSD 15 — баланс классики и новых возможностей

  3. FreeBSD 16 — свежий релиз для тех, кто хочет максимум актуальных фич

Хороший выбор для сетевых сервисов, хранилищ на ZFS и проектов с высокими требованиями к безопасности и стабильности.

Чем хороша FreeBSD:

1️⃣ UNIX-система: предсказуемость и контроль
2️⃣ Сильный сетевой стек: оптимизация под высокие нагрузки и сложные сетевые сценарии
3️⃣ ZFS из коробки: снапшоты, дедупликация и контроль целостности данных
4️⃣ Jails вместо контейнеров: простая и легкая изоляция процессов

Создать сервер с ОС FreeBSD →

Теги:
Всего голосов 9: ↑9 и ↓0+13
Комментарии0

Не только расскажем про железо, но и покажем ⚙️

Регулярно делимся новостями про наше оборудование, а сегодня сделаем это в видеоформате.

Сняли ролик с Владом Олейником, ведущим инженером ЦОД.

Он разобрал серверные платформы ASUS на базе AMD и Intel и рассказал, где их использовать, чем они нам понравились и на что обратить внимание.

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

Смотрим на ютубе, в вк и на рутубе.

Кстати, скоро покажем больше видео про внутрянку облака и интересные кейсы. На очереди — Kubernetes.

Теги:
Всего голосов 9: ↑8 и ↓1+10
Комментарии0

SpaceWeb объединил управление хостингом, VPS и доменами в одном мобильном приложении

SpaceWeb перезапустил мобильное приложение и перевел его на технологию Progressive Web App (PWA). Теперь все ключевые функции управления услугами доступны в одном интерфейсе прямо со смартфона — без ограничений по функциональности.

Приложение полностью повторяет возможности веб-панели управления. Пользователи могут заказывать и контролировать хостинг, VPS/VDS и облачные сервисы, управлять доменами, DNS и SSL/TLS-сертификатами, отслеживать баланс и нагрузку, настраивать доступы. Также доступны пополнение счёта, автоплатежи и участие в партнерской программе.

Переход на PWA позволил синхронизировать обновления: все новые функции, которые появляются в основной панели управления, сразу становятся доступны и в мобильной версии.

Все подробности о перезапуске — на сайте SpaceWeb.

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Русский хакер взломал почту президента Соединенных Штатов Америки Дональда Трампа!

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

Одним из самых распространенных методов обмана людей была и остается рассылка по электронной почте. Еще до индусских колл-центров и служб безопасности банков, в начале нулевых главным средством выманивания денег были африканские e-mail'ы, которые с сожалением сообщали о кончине вашего родственника, но завещавшего вам пару десятков миллионов долларов 🇷🇺.

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

Главными критериями определения легальности письма являются 2 доменные записи: SPF и DMARС (есть еще DKIM, который отвечает за цифровую подпись писем, но о нем как-нибудь в другой раз).
Sender Policy Framework aka SPF — это запись со списком серверов и IP-адресов, с которых разрешается рассылать письма от имени домена. Если письмо пришло с отличного от записанного в SPF айпишника или домена - письмо помечается как подозрительное.
Domain-based Message Authentication, Reporting and Conformance aka DMARC — это политика, которая задаёт сценарий действий с письмами, которые признаны через SPF подозрительными: none - ничего не делать, quarantin - пропускать, но поместить в папку спам, и reject - отклонять.

Соответственно, если у домена в DNS не прописаны SPF и DMARС, то принимаемый mail-сервер не может проверить легальность отправления и не понимает, что с ним делать дальше кроме как пропустить.
Так и случилось в текущем примере: коммерческий домен POTUS.com не имеет соответствующей записи DMARC и любой желающий может отправлять письма от его имени, включая якобы действующего президента 🇺🇸 США.

К счастью, большие почтовые корпорации типа 📧 Google и ❤️ Яндекс, даже при отсутствии или неправильной конфигурации SPF и DMARC, научились отличать фишинг от реального письма. Однако ряд других почтовиков (не будем показывать пальцем) не только пропускают такие письма, но еще и подставляют аватарки (на основе фавиконки с домена), а под письмом пишут, что оно проверено "докторским" антивирусом.

Как же установить, что проверяемый домен подвержен такой атаке? Ранее я пользовался встроенной в Kali утилитой под названием spoofcheck (проверка на спуффинг), но она просто проверяет DNS записи и говорит возможно ли заспуфить проверяемый домен или нет.
Поэтому около года назад я сделал свою утилиту 🧠 HydrAttack PoC eMailSpoofer Module, которая проверяет домен на уязвимость (чекает DNS записи), и если так оно и есть - поднимается майл сервер со всеми необходимыми настройками и отправляется спуффинговое письмо. Особенностью моего ПО является то, что в письмо вложен Excel файл с макросом, который открывает калькулятор.

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

🧠 Обязательно поделись с теми, кому это может быть полезно 📱 Телеграм | 📝 Хабр | 💙 ВКонтакте | ⚡️Бустануть канал

*President of the United States - Президент Соединенных Штатов

Теги:
Всего голосов 3: ↑0 и ↓3-3
Комментарии0