Брать или не брать? Вся правда о новых Scalable и порция свежих тестов



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

В этот раз «под микроскопом» оказались два поколения Intel Xeon Scalable: 8 процессоров, по четыре на каждое поколение.
  • Первое поколение — Silver 4110, Silver 4114, Gold 6130, Gold 6140.
  • Второе поколение — Silver 4210, Silver 4214, Gold 6230, Gold 6240.

Чтобы не спойлерить, предлагаем заглянуть в статью «Найди пять отличий. Разница поколений Scalable и — новая порция тестов» и узнать, какое поколение показало лучшие результаты и что же такого особенного во втором поколении Scalable, выпуск которых Intel считает важным стратегическим шагом. А заодно найти ответ и на шекспировский вопрос.

Любой сервер из статьи можно заказать на сайте 1dedic.ru.
При оплате за год — скидка на любой сервер 10%.

Найди пять отличий. Разница поколений SCALABLE и новая порция тестов




Не прошло и два года с момента анонса, как Intel представила второе поколение процессоров Intel Xeon Scalable на новой архитектуре Cascade Lake. Официально — 2 апреля. Сама компания называет это крупнейшим запуском в своей истории, стратегически очень важным для неё. Что ж, давайте разбираться, что в этих новых Scalable такого особенного.

Что оставили?
Процессоры Cascade Lake, а точнее Cascade Lake SP, как и их предшественники Skylake, всё так же относятся к платформе Purley, теперь уже второго поколения — Purley Refresh. Они полностью совместимы со Skylake на уровне разъёма, чипсетов и материнских плат, доставшихся по наследству от первого поколения. Но с нюансами — например, новый bios.

Не изменился техпроцесс. Те же 14 nm, правда, с оптимизациями.

Общая схема наименований и названий для серий Platinum, Gold, Silver, Bronze осталась прежней. Правда, «суффиксов» стало больше. К имеющимся L, M и T добавились новые Y, N, V и S. В нумерации сменилось значение второй позиции (сотни): теперь вместо единицы — двойка, то есть преемником, например, Gold 6140 будет Gold 6240. В остальном базовые характеристики и набор возможностей не изменились. Число ядер и объёмы кэшей держат позиции: до 28 и по 1 Мбайт L2 на ядро + до 38,5 Мбайт общего L3. Число и тип линий PCI-E такие же, как были, — 48 линий версии 3.0. Масштабируемость та же: до 3 линий UPI на 10,4 GT/s и до 8 (бесшовно) сокетов в системе.

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

Во-первых, в Cascade Lake появились аппаратные заплатки против нашумевших в прошлом году уязвимостей. Intel представил программно-аппаратные решения против вариантов 2 (Spectre), 3, 3a и 4 (Spectre NG), L1TF (Foreshadow). Для Spectre Variant 1 всё так же предлагается только программный патч. То есть всё то, что уже есть в линейке Intel Core i9. А так это выглядит в пресс-релизе:
  • Вариант 1. Защита осуществляется средствами ОС и VMM (Virtual Machine Monitor)
  • Вариант 2. Hardware Branch Prediction Hardening (предотвращение будущих атак по данному методу) + средствами ОС и VMM
  • Вариант 3. Hardware Hardening Вариант 3a. Hardware
  • Вариант 4. Hardware + ОС/VMM L1TF. Уже закрыта благодаря Hardware Hardening в варианте 3
Во-вторых, появилась поддержка памяти DDR4-2933. Но с оговорками: только для линеек Gold и Platinum (Bronze и Silver по-прежнему работают с DDR4-2400) и только с одним DIMM на канал — в конфигурации с двумя DIMM на канал частота снижается до 2666 MT/s.

В-третьих, состоялась премьера Intel Optane DC Persistent Memory (DCPM). Самая четкая формулировка о том, что это такое, получилась у Тискома, поэтому цитирую:
Intel Optane DC Persistent Memory (DCPM) — новый класс технологий, сочетающий те понятия, которые называются «memory and storage» и предназначаются для использования в центрах обработки данных

Может помните, ранее Intel представлял технологию Intel Memory Drive Technology для Xeon Skylake: гипервизор (Xen) + NVMe-модули Optane. У нас даже случились тесты по этому поводу, но результаты были не вдохновляющие, и мы решили подождать более впечатляющего решения. Кажется, дождались =)

В основе нового решения от Intel лежат модули DCPMM, визуально похожие с DIMM, а также электрически и механически совместимые с ними. Работают на скорости 2666 MT/s и имеют объём 128/256/512 Гбайт. На логическом уровне используют протокол DDR4-T (Transaction), который, по словам Intel, одобрен JEDEC, но на практике его поддержка есть только в контроллерах памяти Cascade Lake. То есть на разъём DIMM DDR4 посадили энергоНЕзависимую память, выполненную по технологии 3D XPoint, обгоняющую, опять же со слов Intel, широко распространённую NAND Flash на три порядка (в 1000 раз) по таким характеристикам как скорость и срок службы.

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

В-четвёртых, технологии Intel Resource Director Technology (RDT), Speed Select (SST) и Intel DL Boost прокачались по скиллам. Начну с RDT. Он представляет собой механизмы достаточно тонкого мониторинга и контроля над исполнением приложений и использованием ресурсов. Штука не новая, но в данной линейке к ней хорошо приложили руки и детально проработали. Суть в том, чтобы приложение с более высоким приоритетом вовремя получало всё, что ему нужно. Естественно, за счёт «ущемления в правах» других приложений.

Теперь SST. Тут то же самое, но на уровне ядер: позволяет жёстко выделять группу ядер, которая будет иметь повышенный приоритет над другими. Появление в этот раз не дебютное, но вполне эффектное.

И на десерт Intel DL Boost. Нововведение касается нового набора инструкций, известного ранее как Vector Neural Network Instructions (VNNI). Штуковина для ИИ, а точнее, для более гибкой тренировки сетей глубокого обучения. По сути ещё одна надстройка над AVX-512.

И наконец, в-пятых. По старой традиции для рефрешей от Intel — больше частоты, больше ядер :-) Как базовые частоты, так и частоты в бусте подросли на 200-300 МГц. За некоторым исключением добавилось по два ядра на процессор. Увеличился объём поддерживаемой оперативной памяти. Отдельно стоит отметить работу Intel по оптимизации использования кэшей и оперативной памяти, вероятно, для минимизации негативного влияния заплаток от уязвимостей семейства Spectre и Meltdown.

Более детально с особенностями архитектуры Cascade Lake можно ознакомиться на wikichip. Рекомендую к прочтению. А теперь — уже традиционное тестирование.

ТЕСТИРОВАНИЕ
В тестировании участвуют восемь процессоров Intel Xeon Scalable:
  • первое поколение — Silver 4110, Silver 4114, Gold 6130, Gold 6140,
  • второе поколение — Silver 4210, Silver 4214, Gold 6230 и Gold 6240.


Тактико-технические характеристики платформ
  • Все процессоры имеют одинаковую базовую конфигурацию.
  • Платформа: Intel Corporation S2600WFT (BIOS SE5C620.86B.02.01.0008.031920191559)
  • Оперативная память:
  • 16 Гб Samsung DDR4-2933 — 12 штук (по одной на каждый канал) для процессоров Gold 6230 и 6240
  • 16 Гб Samsung DDR4-2666 — 12 штук (по одной на каждый канал) для процессоров Gold 6130 и 6140
  • 16 Гб Samsung DDR4-2400 — 12 штук (по одной на каждый канал) для процессоров Silver обоих поколений
  • SSD-накопитель: Intel DC S4500 480 Гб — 2 штуки в RAID1
  • Двухпроцессорная конфигурация
  • Программная часть: ОС CentOS Linux 7 x86_64 (7.6.1810)
  • Ядро: 3.10.0-957.12.2.el7.x86_64

Внесённые оптимизации относительно штатной установки: добавлены опции запуска ядра elevator=noop selinux=0

Тестирование производится со всеми патчами от атак Spectre, Meltdown и Foreshadow, бэкпортироваными в данное ядро.

Список тестов, которые будем проводить:
  • Geekbench
  • Sysbench
  • Phoronix Test Suite

РЕЗУЛЬТАТЫ ТЕСТИРОВАНИЯ



В тесте Geekbench в однопоточном и многопоточном варианте новые Scalable обходят старые по всем позициям. В однопоточном тесте от 3% до 6%, в многопоточном от 6% до 13%, и апофеоз — Silver 4210 лучше Silver 4110 аж на 33%.


В тесте Sysbench разница от 22% до 37%. Минимальный разрыв между Gold 6140 и Gold 6240 — 7% в пользу нового.


В тесте John The Ripper Silver 4210 обгоняет Silver 4110 на 41%, а между Silver 4214 и Silver 4114 разница почти на 30% — естественно, в пользу первого. Теперь голды. Gold 6230 быстрее Gold 6130 на 16%. Минимальный разрыв между Gold 6140 и Gold 6240 — 7,6%.


Silver 4210 обгоняет Silver 4110 на 29%, а Silver 4214 предшественника на 23%. Разрыв между парами Gold 20% и 8% соответственно.


В однопоточном тесте Himeno можно увидеть чистый прирост 200-300 Мгц — от 2,2% до 6% в пользу нового поколения.


Тест compress-7zip почти полностью копирует результат теста John The Ripper: Blowfish. Красивый отрыв между Silver 4110 и Silver 4210: 4210 почти на 35% быстрее своего предшественника. Silver 4214 и Gold 6230 на 18% и 20% соответственно лучше 4114 и 6130. Минимальный разрыв между Gold 6140 и Gold 6240: новый лучше прежнего на 4,7%.


В тесте compress-pbzip2 картина аналогична тесту compress-7zip. Из существенных отличий — уменьшился разрыв между Gold 6130 и Gold 6230, здесь он составляет 5,6%.


В однопоточном тесте Encode-mp3 снова видим разницу 200-300 МГц. От 4% до 7% — на столько Scalable второго поколения лучше первого в этом тесте.


В тесте openssl самый большой разрыв между Silver 4110 и Silver 4210 — 41%. Между 4114 и 4214 — 29%. У голдов поменьше. Между Gold 6130 и 6230 — 23%. И в паре Gold 6140 и 6240 — 4,6%. Замечу, что Gold 6240 всего на 0,78% лучше Gold 6230.


В тесте Apache Silver 4210 лучше Silver 4110 на 40%, Silver 4214 обгоняет Silver 4114 на 36%, Gold 6230 лучше Gold 6130 на 21% и Gold 6240 проходит этот тест лучше Gold 6140 на 29%. Особо заострю внимание на Silver 4210, Silver 4214 и Gold 6230: Gold 6230 на 3% лучше Silver 4210 и на 1,5% лучше Silver 4214. То есть разрыв минимален. Gold 6240 на 13% лучше Gold 6230.


В тесте GCC новое поколение обгоняет своих предшественников примерно на 19%, 16%, 11% и 9,5% соответственно.


Что получается в итоге.
Наблюдаем, значительный разрыв между Silver 4110 и Silver 4210 — новое поколение лучше предыдущего в многопоточных тестах примерно от 20% до 40%. Спасибо вам, частоты и ядра.

Между Silver 4114 и Silver 4214 разница уже меньше: тестовый максимум — в тесте Apache доходит до 36%.

Далее разрыв сокращается. Gold 6230 обгоняет Gold 6130 в пределах от 11% в тесте GCC и до 23% в тесте OpenSSL.

И наконец, минимальный разрыв у пары Gold 6140 и Gold 6240: новый опережает предыдущий на 3%-10% по результату большинства тестов. Исключение тест Apache: разница на 28% — меньше ядер, больше базовая частота (Apache вообще очень интересный тест).

А теперь переходим к дополнительным тестам. Но сначала краткая предыстория.

ТЕСТИРОВАНИЕ ОПЕРАТИВНОЙ ПАМЯТИ
Новые процессоры Intel Xeon Scalable линейки Gold 62xx стали поддерживать новый тип оперативной памяти DDR4-2933. Мы, что вполне логично, задались вопросом: насколько сильно частота оперативной памяти повлияет на общую производительность системы. Вообще, если исходить из предположения, что плюс на плюс всегда дает нечто положительное, верилось в то, что свежий процессор в паре с новой памятью покажут себя молодцами. Но одно дело предполагать, а другое — убедиться экспериментальным путём.

Для теста мы взяли процессор Gold 6240 в двухпроцессорной конфигурации. Тактико-технические характеристики платформы и программная составляющая не изменились. Память будем тестировать такую: DDR4-2400, DDR4-2666 и DDR4-2933.

Всегда радует, когда под рукой есть всё самое необходимое для проверки гипотез =) А теперь идём смотреть, что из этого получилось.
РЕЗУЛЬТАТЫ ТЕСТИРОВАНИЯ ОПЕРАТИВНОЙ ПАМЯТИ
Когда слишком хорошо — это уже плохо. Поэтому я решил отказаться от идеи рисовать все графики и свёл результаты в таблицы — удобнее и быстрее, хотя и менее наглядно. Графики тоже будут, но лишь самые интересные, на мой взгляд.






«Либо мы делаем что-то не так, либо одно из двух».
Цитата братьев Пилотов, пусть и слегка перефразированная, оказалась как нельзя кстати после того, как тестирование памяти было завершено…

Как и во всех тестах, мы сделали десять замеров и выбрали средние по ним показатели. Как видите, показания тестов разнятся так же сильно, как показания гражданки Кроликовой из кинофильма «Ширли-мырли».

В тестах Phoronix 50 на 50 высокие результаты показывают конфигурации с ОЗУ 2400 и 2933 МГц. Тест Geekbench заценил 2933 память по параметрам Memory Score_Single и Memory Score_Multi, но общий результат удивляет.

Из предположений — влияние большей частоты на latency. А отсюда баланс между скоростью и временем отклика. Но, честно говоря, не уверен… Если есть, что сказать по этому поводу — прошу в комментарии.

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

МАЛЕНЬКИЙ ШАГ ДЛЯ ЧЕЛОВЕКА, НО ОГРОМНЫЙ — ДЛЯ ЧЕЛОВЕЧЕСТВА
Как сказал бы товарищ Камнеедов (люблю я Стругацких), «примерно в таком аксепте» Intel и позиционирует новую линейку процессоров Xeon Scalable. Еще в начале статьи я говорил, что выход новых Scalable для самого Intel — важный стратегический шаг. Теперь поясню.

С одной стороны, новые Scalable положили начало глобальному обновлению платформы для центров обработки данных. И уже во второй половине года нас ожидает парочка интересных анонсов. С другой, все нововведения не случайны — это ответ на текущие запросы индустрии. И вполне себе достойный ответ. Мало памяти? Вот вам Optane DC Persistent Memory. Хотели аппаратную приоритезацию процессов и ядер? Пожалуйста, прокачали SST и RDT. Мечтали о профессиональной тренировке сетей? :-) Вот, распишитесь, новый набор инструкций для ИИ. За Intel можно только порадоваться.

Хотя, лично у меня, складывается впечатление, что в данный релиз вошли «хотелки», которые Intel не успели реализовать в прошлый раз. И, конечно, что-то нужно было делать с аппаратными дырами, поиск которых для разных спецов стал уже своеобразным развлечением. Всё, что Intel отобрал у пользователя дырами Спектрами-Мелтауны, он теперь вернул, сохранив цену.

К тому же со всех сторон наступает AMD, чьи решения в значительно меньшей степени оказались подвержены негативному влиянию Спектра-Мелтдаунов, и которая в последнее время особенно «труба шатал» Intel как в десктопном (хотел бы я иметь в таком солидном возрасте подобную моложавость), так и слегка в серверном сегменте. Кстати, в плане последнего очень интересно посмотреть, как покажут себя новые AMD Epyc Rome, так как нынешнее поколение Epyc лично меня не оставило равнодушным.

Но вернемся к Scalable.
Что же в сухом остатке получает пользователь, не отягощенный ИИ и тренированными сетями? Однозначно явный прирост производительности за счёт большего количества ядер, более высоких базовых частот и частот в турбобусте. И если для процессоров Gold разных поколений этот прирост в максимуме достигает 23% — хороши и те, и другие, то для Silver в некоторых тестах доходит до 40%. С учётом почти не изменившейся стоимости разница вполне приятная, хотя мне как всегда хочется большего =)

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

В тестировании использовались серверы на базе процессоров Intel Xeon Scalable: Silver 4110, Silver 4114, Silver 4210, Silver 4214, Gold 6130, Gold 6140, Gold 6230, Gold 6240.

Для вас тестировал и писал Григорий Прадедов, старший системный администратор отдела эксплуатации FirstDEDIC

https://firstdedic.ru

Как настроить VLAN на двух и более выделенных серверах



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

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

Посмотреть, что за услуга VLAN и сколько стоит.
1dedic.ru/additional/vlan

ВЫ ПРИОБРЕЛИ УСЛУГУ, ЧТО ДАЛЬШЕ
Чтобы объединить выделенные серверы на Linux или на Windows в локальную виртуальную сеть, первое, что вы должны сделать, — это составить запрос в службу технической поддержки на подключение выделенных серверов вторыми сетевыми адаптерами в коммутатор.

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

Например, следующие:
  • 10.0.0.0/8;
  • 172.16.0.0/12;
  • 192.168.0.0/16.

После того, как вы определились с IP-адресами, можно приступать к настройке.

Подробнее
1dedic.ru/articles/kak-nastroit-vlan-na-dvuh-i-bolee-vydelennyh-serverah

Как мы запустили в Яндекс.Облаке сервис распределённых очередей сообщений



Привет, меня зовут Василий Богонатов. Я один из тех, кто приложил руку и голову и вложил свою душу в сервис распределённых персистентных очередей сообщений Yandex Message Queue. Сервис вышел в общий доступ в конце мая, но внутри Яндекса он уже давно и активно используется в разных продуктах.

Сегодня я хочу рассказать читателям блога об очередях сообщений вообще и о Yandex Message Queue в частности. Сначала я хочу объяснить, что такое «распределённая персистентная очередь сообщений» и зачем она нужна. Показать её практическую ценность, механику работы с сообщениями, поговорить про API и удобство использования. Во второй половине материала мы посмотрим на техническую сторону: как в наших очередях используется Yandex Database (это надежный фундамент нашего сервиса), как выглядят наивный и улучшенный подход к построению архитектуры, какие проблемы вызывает распределённость и как их можно решить.


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

Мы немного уточним термины.

Очередь сообщений — это хранилище, которое обеспечивает размещение и чтение данных в определённом порядке.

С очередью обычно взаимодействуют два типа сущностей:
  • писатели (producers) — отправляют сообщения в очередь;
  • читатели (consumers) — получают (читают) сообщения из очереди.
Основной сценарий для очереди: надёжно и быстро передавать сообщения от писателя к читателю. В отличие от базы данных очередь не предназначена для длительного хранения сообщений. Во многих популярных реализациях существует соответствующий параметр — «Срок хранения сообщений». Он определяет, сколько времени хранится сообщение до момента безвозвратного удаления.

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

Подробнее
cloud.yandex.ru/blog/posts/2019/06/message-queue

Недоступность сервисов Яндекс.Облака 17 июня 2019 года



17 июня с 7:35 до 12:05 пользователи Яндекс.Облака испытывали сложности с доступом к сервисам Яндекс.Облака через консоль и API. Хотим рассказать подробнее о случившемся.

Что произошло?
В 7:35 в рамках регулярных работ по диагностике сети был перезагружен коммутатор в одной из стоек зоны доступности ru-central1-a. В 7:43 наши дежурные зафиксировали на внутренних мониторингах отсутствие доступа к сервисам через консоль или API. При этом data plane сервиса виртуальных машин Yandex Compute Cloud, сервисов управляемых баз данных и остальных сервисов работал в штатном режиме.

Дежурные инженеры определили, что причина недоступности в одном из вспомогательных компонентов внутри системы хранения метаданных Яндекс.Облака. Ошибка была локализована в 10:18, и в 11:37 сборка с исправленной ошибкой была выкачена.

В 12:05 все сервисы Яндекс.Облака вернулись в рабочее состояние.

Причины
Сервисы Яндекс.Облака хранят метаданные в высокодоступном сервисе с кодовым названием Yandex Database (YDB), который состоит из полностью независимых баз данных (по одной на каждый сервис), каждая из которых распределена между тремя зонами доступности и переживает выход любой из них из строя без потерь. Единственный компонент внутри YDB, общий для всех баз данных, — это база для хранения метаданных самой YDB и компиляции запросов к другим базам.

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

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

База метаданных спроектирована таким образом, что после сбоя штатным образом поднимается заново на любой доступной ноде и восстанавливает свое состояние с дисков из лога изменений. Обычно рестарт базы занимает незначительное время (<1c), а time-to-live (TTL) пре-компилированных запросов был установлен в несколько минут. Но из-за программной ошибки, которая бы не проявилась без вышеописанного стечения обстоятельств, база не смогла корректно восстановить свое состояние в сроки установленного TTL.

Меры для предотвращения повторения подобной ситуации в будущем:
  • Как мы уже упомянули, программная ошибка в базе метаданных была исправлена во время устранения инцидента.
  • Мы уже увеличили TTL пре-компилированных запросов до 6 часов во всех сервисах Яндекс.Облака.
  • Мы увеличиваем долговременную тестовую нагрузку на базу метаданных. В pre-production кластерах Яндекс.Облака база метаданных будет работать с принудительными сбоями.
  • Мы реализуем шардирование базы метаданных между другими базами данных.
Мы приносим свои извинения всем пользователям, кого затронул данный инцидент. Компенсации пользователям будут начислены не позднее 28 июня 2019 года согласно соглашению об уровнях обслуживания соответствующих сервисов Яндекс.Облака при обращении в поддержку.

DNS Management gets a facelift



Коксовые бутылки сложены на полу, запах мускусный сгущается воздух, маленький свет, который входит в нашу комнату, кажется, отступать от отвращения. Мы были скрываясь в тени в течение двух месяцев, но уборщики были призваны и мы, наконец, выпустили наше самое захватывающее обновление в течение года… наш новый интерфейс управления DNS!
Хорошо, это может быть не так интересно для всех, но нашей помощи свежа и наша гордость чиста. Мы считаем, что мы построили что-то особенное!

Давайте посмотрим правде в глаза, в то время как наш Free DNS является лучшим, что было трудно смотреть на него. С редизайн нашего интерфейса управления DNS, мы решили добавить некоторые новые функции, чтобы сделать управление DNS простым:
  • Способность планировать изменения, как ределегирование и зоны записи изменений. Если у Вас есть высокое изменение воздействия, чтобы сделать, вы можете запланировать его на рекордно низком уровне воздействия без необходимости установки будильника!
  • Ваша зона и делегирование история теперь будет видна вам, с временными метками. Так что если вы сделаете ошибку, то легко откатить.
  • Мы собрали все под одной странице.
  • Вы можете добавлять или редактировать записи, используя выпадающий, не более прокрутки страницы вниз!
  • Это выглядит намного лучше!

Мы надеемся, что вам понравится :) Отправить нам чириканье @InternetBs если вы делаете.
Мы приветствуем ваши отзывы о последнем запуске или каких-либо предложений, которые могут помочь упростить для вас.
internetbs.net/en/domain-name-registrations/login.html

Предпосылки и результаты замены коммутатора на 7 кластере



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

Всё началось с того, что мы обратили внимание на ряд факторов, которые указывали на необходимость оптимизацию программного коммутатора и замену аппаратного. Среди них можно выделить следующие обстоятельства:
  • Было выявлено появление жалоб на «квакание» от клиентов, которые использовали «Teamspeak», «Asterisk» и другие приложения, в основе которых лежит передача голосового трафика. Наличие данной проблемы свидетельствовало о потере полезных пакетов на сети. Появление эффекта можно объяснить тем, что IP-телефония для передачи данных использует протокол UDP. В данном протоколе отсутствует сценарий, по которому происходит повтор передачи потерянного пакета заново, в следствии этого, голосовое сообщение доходит до получателя в искажённом виде.
  • Было зафиксировано, что обращения, которые касались работы VDS и не были связаны с потерей пакетов трафика, по статистике протокола TCP, выделялись высокими значениями счётчика Retransmit. Его показатели свидетельствуют о необходимости передачи потерянных пакетов.
  • В показателях статистики compute-нод были зафиксированы высокие показатели счётчиков rxfifo_error, которые также свидетельствуют о дропах пакетов по различным причинам.
  • Большие показатели счётчиков discard.

В рамках оптимизации стека было осуществлено вертикальное расширение. В ходе его реализации мы произвели следующие улучшения:
  • Осуществили переход на jumbo-frame, что увеличило показатель MTU до 9000. Это позволило увеличить миграцию и процесс создания новых VDS, а также утилизировать полную пропускную способность интерфейса.
  • Провели оптимизацию программного коммутатора на compute-нодах (bridge).
  • Провели оптимизацию настроек сетевых карт compute-нод. Начало работы над оптимизацией сетевого стека указало на необходимость замены коммутатора.

Расскажем, почему же понадобилась его замена:
  • Каждый коммутатор обладает буфером передачи данных, который почти всегда используется при переходе между интерфейсами с разными скоростями. Замена позволит увеличить буфер передачи до 1 Gb.
  • Новый, более мощный коммутатор необходим для возможности горизонтального расширения сетевого кластера. Нами был выбран коммутатор HР 5830.
  • Миграции, DDoS атаки, осуществляемые мелкими пакетами, а также повышенное потребление трафика может приводить к исчерпанию лимита буфера передачи данных, что влечёт замедление передачи данных на всех нодах. В качестве основного сигнала можно выделить появление множества уведомлений, свидетельствующих о наличии проблемы с исчерпанием лимита.

После успешного проведения оптимизации сетевого стека нами были проведены работы по замене коммутатора на 7 кластере. В ходе их реализации было сделано следующее:
  • Извлечение коммутатора IPMI;
  • Перенос основного коммутатора;
  • Установка нового коммутатора;
  • Переключение внешних портов на новый коммутатор;
  • Организация двух воздуховодов для нового коммутатора;
  • Упорядоченное переключение серверов;
  • Осуществление процедур по наведению порядка и проверке корректности работы коммутатора. Замена коммутатора позволила увеличить скорость передачи данных на всех нодах.

Пакет услуг для запуска сайта «Бизнес-Старт» за 159 рублей!



Пакет «Бизнес-Старт» — готовое решение для запуска бизнеса в Сети. Мы собрали в одном пакете всё, что нужно для старта современного онлайн-проекта:
  • Домен .ru — флагманский домен Рунета и один из самых узнаваемых среди всех национальных доменов мира.
  • Виртуальный хостинг — хостинг по тарифу «200» с простой панелью управления, поддержкой всех популярных CMS-систем, почтой и антивирусом.
  • SSL-сертификат Symantec Starter — базовый сертификат, активирующий https-соединение для безопасной передачи данных и улучшения позиций сайта в поисковой выдаче.
Протестируйте свою бизнес-идею и сэкономьте на старте — до 10 июля пакет услуг «Бизнес-Старт» всего за 159 руб. по промокоду STARTGIFT20.
www.nic.ru/solution/25-ru

Домен .amazon снова заморожен

Месяц назад мы сообщали о волевом решении ICANN разрешить регистрацию домена .amazon, после того как Амазонский пакт в очередной раз сорвал переговоры. Казалось, это решение было окончательным.

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

Среди прочего в них предлагалось странам Амазонского региона и Амазонскому пакту дать право на частичное управление доменной зоной .amazon в предназначенных для них доменах второго уровня. То есть страны получат в своё распоряжение зоны co.amazon, br.amazon и т.д. Правительство Колумбии сослалось на пример зоны .SAS, где две компании, владеющие идентичным товарным знаком SAS, договорились распределить между собой управление доменной зоной.

В результате статус зоны .amazon снова был изменен на «в ожидании» (on hold), и, возможно, надолго. Ведь даже рассмотрение срочных запросов, согласно правилам ICANN, организация может вести до 90 дней, т.е. до октября этого года.

www.webnames.ru