Уважаемые абоненты, в рамках продолжения цикла улучшений услуги Cloud2 мы увеличили частоту vCPU для экземпляров LowCPU в 2 раза. Теперь частота ядра составляет 2 GHz, ранее была 1 GHz. Это означает, что машины LowCPU теперь будут работать в два раза быстрее.

Для активации новой частоты необходимо остановить машину в панели и запустить ее снова.

Мы по-прежнему не рекомендуем машины LowCPU для нагруженных проектов, позиционируя их как решения для малых серверов специальных нужд — DNS, VPN, Proxy, FTP, балансировщик Nginx и т.п. Для сервисов, которым требуется высокая производительность и низкая задержка обработки выбирайте только машины HighCPU или Ultra (скоро будут доступны).

Спасибо за то, что вы выбираете наши услуги.
billing.netpoint-dc.com/billmgr?func=register&lang=ru

Для проектов, требовательных к скорости, делаем шаг вперед: в три раза увеличиваем объем доступного трафика на гигабитном канале! Теперь лимит составляет 30 терабайт (30 720 гигабайт). Стоимость превышения остается прежней — 0,5 р. за ГБ.

При заказе нового сервера выбрать гигабитный канал можно в параметрах заказа.
Заказать сервер с гигабитным каналом
1dedic.ru
Для работающих серверов, еще не использующих гигабитный канал — напишите запрос в службу поддержки, внесем необходимые изменения. Перенастройки и перезагрузки сервера не потребуется.
my.1dedic.ru/billmgr

Сегодня мы рады сообщить, что Google Cloud Platform (GCP) — первый крупный поставщик облачных вычислений, предлагающий доступность для графического процессора NVIDIA Tesla T4. Теперь доступный в альфа, T4 GPU оптимизирован для вывода машинного обучения (ML), распределенной подготовки моделей и компьютерной графики.

Быстрый, экономически эффективный вывод ML
По сравнению с другими методами искусственного интеллекта вывод ML требует особо высокопроизводительных вычислений с низкой задержкой. Благодаря поддержке Turing Tensor Core для прецизионных режимов FP32, FP16, INT8, NVIDIA Tesla T4 обеспечивает до 130 TFLOPS производительности вывода вывода ML с задержкой до 1,1 мс *. Кроме того, 16-гигабайтная высокоскоростная память GPU T4 помогает поддерживать как крупные модели ML, так и выполнять вывод на нескольких моделях ML одновременно для большей эффективности вывода. Наконец, T4 является единственным графическим процессором, который в настоящее время предлагает поддержку точности INT4 и INT1 для еще большей производительности.

Предлагая недорогой вариант для обучения моделях ML
Многие из вас также сказали нам, что вы хотите, чтобы GPU поддерживал вычисления с медной точностью (как FP32, так и FP16) для обучения ML с отличной ценой / производительностью. 65 TFLOPS T4 для гибридных FP32 / FP16 ML и 16 ГБ памяти GPU решают эту потребность для многих распределенных тренировок, обучения подкреплению и других нагрузок ML. Цены на T4 будут доступны во время бета-объявления.

Нагрузочные графические рабочие нагрузки
Благодаря новым графическим функциям с аппаратным ускорением Tesla T4 также является отличным выбором для требовательных графических рабочих нагрузок, таких как трассировка лучей в реальном времени, автономный рендеринг или любое приложение, использующее технологию RTX от NVIDIA. Архитектура Тьюринга T4 позволяет спланировать трассировку лучей в реальном времени, AI, имитацию и растеризацию, чтобы обеспечить новый многоуровневый подход к рендерингу компьютерной графики. В то же время специализированные процессоры трассировки лучей, называемые RT Cores, могут отображать, как лучи света движутся в трехмерных средах.

Мы хотим упростить вам использование Tesla T4. Вы можете быстро начать работу с Compute Engine (GCE) с помощью наших изображений Deep Learning VM, которые предварительно настроены на все, что вам нужно для выполнения высокопроизводительных рабочих нагрузок. Кроме того, поддержка T4 скоро появится в Google Kubernetes Engine (GKE) и других службах GCP.
cloud.google.com/deep-learning-vm/

В режиме реального времени визуализация и интерактивные нагрузки на вывод требуют низкой латентности для конечных пользователей. Продвинутые в отрасли сетевые возможности GCP вместе с нашим предложением T4 позволяют вам внедрять инновации по-новому, ускоряя ваши приложения, одновременно сокращая затраты. Масштаб GCP позволяет вам перейти от разработки к развертыванию на производство на тысячи графических процессоров с помощью простого вызова API. Вы также можете оптимизировать цену и производительность, подключив до 4 T4 графических процессоров в любую пользовательскую форму виртуальной машины.
cloud.google.com/custom-machine-types/

Зарегистрироваться
Вы можете зарегистрироваться для раннего доступа к NVIDIA T4 на GCP здесь. Доступность во время альфы ограничена, поэтому зарегистрируйтесь сейчас. Для получения дополнительной информации посетите страницу нашего GPU.
docs.google.com/forms/d/e/1FAIpQLSfc_5IyMpoIsgQ3vNggPvKkTjlI1wbb4WDSbYWFkvZdh2orOw/viewform

14 ноября 2018 возможна кратковременная недоступность Личного кабинета. С 7:00 по МСК проводим плановые работы с биллинговой системой.

Управляйте своими данными всего несколькими шагами и с помощью нашего нового и простого решения для хранения данных: Nextcloud
www.hetzner.com/storage/nextcloud

OVH присоединяется к новому объявленному Фонду в Ceph качестве члена-основателя

www.itnewsonline.com/prnewswire/The-Linux-Foundation-Launches-Ceph-Foundation-To-Advance-Open-Source-Storage/618587

Компания Comodo CA, крупнейший поставщик SSL сертификатов, провела ребрендинг и теперь называется Sectigo.

По словам генерального директора Sectigo Билла Хольца (Bill Holtz), ребрендинг был необходим, чтобы выйти на более широкий рынок решений для онлайн-безопасности и ликвидировать путаницу, которая образовалась в связи с отделением Comodo CA от Comodo Group. Обе компании работают на одних и тех же рынках и при этом являются разными юридическими лицами.

Компания сменила не только цвета фирменного стиля, логотипы и название, но так же решила поменять названия некоторых продуктов и печать доверия. Скоро любые сертификаты бренда Comodo будут иметь подпись «powered by Sectigo».

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

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

И самое главное. Обновленная компания сообщила, что цифровые сертификаты Sectigo будут продаваться по той же цене, что и их эквиваленты Comodo CA.

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

firstvds.ru

При совершении заказа с сайта lite.host, системные доменные имена формировались вида u1697713101435.p-host.in, согласитесь, такой домен запомнить очень сложно.

Чтобы системные доменные имена стали более красивыми и запоминающимися, мы стали использовать зарубежные имена и фамилии. Теперь доменное имя может выглядеть значительно симпатичнее, например breana.p-host.in.

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

Так выглядит тестовый сайт на каждом сервере виртуального хостинга

Замеряется скорость и успешность ответа сайта. Любой сотрудник компании может посмотреть на общую статистику и увидеть, насколько хорошо идут у компании дела. Может увидеть процент успешных ответов тестового сайта по всему хостингу или по конкретному серверу. Не обязательно быть сотрудником компании – в панели управления клиенты тоже видят статистику по серверу, где размещён их аккаунт.

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

Лето прошло, и график uptime медленно ушёл вниз.


Администраторы сразу же определили причину – нехватка оперативной памяти. В логах легко было увидеть случаи OOM, когда на сервере кончалась память и ядро убивало nginx.

Руководитель отдела Андрей рукой мастера разбивает одну задачу на несколько и распараллеливает их на разных администраторов. Один идёт анализировать настройки Apache – возможно, настройки не оптимальные и при большой посещаемости Apache использует всю память? Другой анализирует потребление памяти mysqld – вдруг остались какие-либо устаревшие настройки с тех времён, когда виртуальный хостинг использовал ОС Gentoo? Третий смотрит на недавние изменения настроек nginx.

Один за другим администраторы возвращаются с результатами. Каждому удалось уменьшить потребление памяти в выделенной ему области. В случае nginx, например, был обнаружен включённый, но не используемый mod_security. OOM тем временем всё также часты.

Наконец, удаётся заметить, что потребление памяти ядром (в частности, SUnreclaim) страшно большое на некоторых серверах. Ни в выводе ps, ни в htop этот параметр не виден, поэтому мы не заметили его сразу! Пример сервера с адским SUnreclaim:

root@vh28.timeweb.ru:~# grep SU /proc/meminfo
SUnreclaim: 25842956 kB

24 гигабайта оперативной памяти отдано ядру, и ядро тратит их неизвестно на что!

Администратор (назовём его Гавриил) бросается в бой. Пересобирает ядро с опциями KMEMLEAK для поиска утечек.
Для включения KMEMLEAK достаточно указать опции, указанные ниже, и загрузить ядро с параметром kmemleak=on.

CONFIG_HAVE_DEBUG_KMEMLEAK=y
CONFIG_DEBUG_KMEMLEAK=y
CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF=y
CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE=10000

KMEMLEAK пишет (в /sys/kernel/debug/kmemleak) такие строки:

unreferenced object 0xffff88013a028228 (size 8):
  comm "apache2", pid 23254, jiffies 4346187846 (age 1436.284s)
  hex dump (first 8 bytes):
    00 00 00 00 00 00 00 00                          ........
  backtrace:
    [<ffffffff818570c8>] kmemleak_alloc+0x28/0x50
    [<ffffffff811d450a>] kmem_cache_alloc_trace+0xca/0x1d0
    [<ffffffff8136dcc3>] apparmor_file_alloc_security+0x23/0x40
    [<ffffffff81332d63>] security_file_alloc+0x33/0x50
    [<ffffffff811f8013>] get_empty_filp+0x93/0x1c0
    [<ffffffff811f815b>] alloc_file+0x1b/0xa0
    [<ffffffff81728361>] sock_alloc_file+0x91/0x120
    [<ffffffff8172b52e>] SyS_socket+0x7e/0xc0
    [<ffffffff81003854>] do_syscall_64+0x54/0xc0
    [<ffffffff818618ab>] return_from_SYSCALL_64+0x0/0x6a
    [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff880d67030280 (size 624):
  comm "hrrb", pid 23713, jiffies 4346190262 (age 1426.620s)
  hex dump (first 32 bytes):
    01 00 00 00 03 00 ff ff 00 00 00 00 00 00 00 00  ................
    00 e7 1a 06 10 88 ff ff 00 81 76 6e 00 88 ff ff  ..........vn....
  backtrace:
    [<ffffffff818570c8>] kmemleak_alloc+0x28/0x50
    [<ffffffff811d4337>] kmem_cache_alloc+0xc7/0x1d0
    [<ffffffff8172a25d>] sock_alloc_inode+0x1d/0xc0
    [<ffffffff8121082d>] alloc_inode+0x1d/0x90
    [<ffffffff81212b01>] new_inode_pseudo+0x11/0x60
    [<ffffffff8172952a>] sock_alloc+0x1a/0x80
    [<ffffffff81729aef>] __sock_create+0x7f/0x220
    [<ffffffff8172b502>] SyS_socket+0x52/0xc0
    [<ffffffff81003854>] do_syscall_64+0x54/0xc0
    [<ffffffff818618ab>] return_from_SYSCALL_64+0x0/0x6a
    [<ffffffffffffffff>] 0xffffffffffffffff

Гавриил не раскрыл нам всех своих тайн и не рассказал, как он из вышеуказанных строк выяснил точную причину утечки памяти. Скорее всего, он использовал команду addr2line /usr/lib/debug/lib/modules/`uname -r`/vmlinux ffffffff81722361 для поиска точной строки. Или просто открыл файл net/socket.c и смотрел на него, пока файлу стало неуютно.

Проблема оказалась в патче на файл net/socket.c, который много лет назад был добавлен в наш репозиторий. Цель его в том, чтобы запретить клиентам использовать системный вызов bind(), это простая защита от запуска прокси-серверов клиентами. Патч свою цель выполнял, но не очищал после себя память.
Возможно, появились новые модные вредоносы на PHP, которые пробовали запустить в цикле прокси-сервер – что и привело к сотням тысяч заблокированных вызовов bind() и потерянным гигабайтам оперативной памяти.

Дальше было просто – Гавриил поправил патч и пересобрал ядро. Добавил мониторинг значения SUnreclaim на всех серверах под ОС Linux. Инженеры предупредили клиентов и перезагрузили хостинг в новое ядро.
OOM исчезли.

Но проблема с доступностью сайтов осталась
На всех серверах тестовый сайт несколько раз в день переставал отвечать.

Здесь автор начал бы рвать волосы на разных частях тела. Но Гавриил сохранял спокойствие и включил запись трафика на части хостинговых серверов.

В дампе трафика было видно, что чаще всего запрос к тестовому сайту падает после внезапного получения пакета TCP RST. Другими словами, запрос до сервера доходил, но соединение в итоге разрывалось со стороны nginx.
Дальше ещё интереснее! Запущенная Гавриилом утилита strace показывает, что демон nginx не отправляет этот пакет. Как такое может быть, ведь только nginx слушает 80-й порт?
Причиной оказалась совокупность нескольких факторов:

• в настройках nginx указана опция reuseport (включающая опцию сокета SO_REUSEPORT), позволяющая разным процессам принимать соединения на одинаковом адресе и порту
• в (на тот момент, самой новой) версии nginx 1.13.0 есть баг, из-за которого при запуске теста конфигурации nginx через nginx -t и использовании опции SO_REUSEPORT этот тестовый процесс nginx действительно начинал слушать 80-й порт и перехватывать запросы реальных клиентов. И при завершении процесса теста конфигурации клиенты получали Connection reset by peer
• наконец, в мониторинге заббикса был настроен мониторинг корректности конфигурации nginx на всех серверах с установленным nginx: команда nginx -t вызывалась на них раз в минуту.

Только после обновления nginx можно было выдохнуть спокойно. График uptime сайтов пошёл вверх.

Какая мораль у всей этой истории? Сохраняйте оптимизм и избегайте использования самостоятельно собранных ядер.

timeweb.com/ru/

RUVDS предоставил возможность клиентам получить рассрочку по карте “Халва” (ПАО «Совкомба́нк»). Облачный провайдер дает держателям карт “Халва” уникальные условия пользования виртуальными серверами VPS/VDS во всех точках присутствия RUVDS в Москве, Лондоне или Цюрихе.
Держатели карт “Халва” получат рассрочку по платежам на все услуги хостинг-провайдера на 3 месяца без переплаты и без процентов.

RUVDS стала первой компанией, предоставляющей услуги IAAS, присоединившейся к партнерской программе “Халва”. По словам управляющего партнера RUVDS Никиты Цаплина, теперь любой желающий может приобрести виртуальный сервер в рассрочку и воспользоваться современной облачной инфраструктурой. Данная услуга поможет при запуске стартапа, когда у компании еще нет собственных средств на покупку серверов и создание своей инфраструктуры.

Справка:
ПАО «Совкомба́нк» — российский универсальный коммерческий банк с головным офисом в Костроме. Входит в двадцатку крупнейших банков России по активам.
RUVDS российский хостинг-провайдер VPS серверов, специализирующийся на оказании услуг IAAS корпоративного класса. Партнерами компании являются АО «ФИНАМ», финансовая группа «БКС», Национальный расчетный депозитарий (Московская биржа), АО «ВЦИОМ», компания «Гарс-Телеком», оператор такси Gett, оператор доставки Delivery Club и многие другие.
Компания RUVDS обладает собственным дата-центром уровня TIER 3 в г. Королеве, Московская область, а также гермозонами в дата-центрах в Цюрихе Interxion ZUR1 (Швейцария), Лондоне Equinix LD8 (Великобритания), и ММТС-9 (Москва, Россия).

ruvds.com
sovcombank.ru