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

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

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

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

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

Ваш офис предназначен для размещения людей или критически важной ИТ-инфраструктуры?
Посмотрим правде в глаза, почти все офисные среды не предназначены и построены для большого, горячего, энергозатратного ИТ-оборудования для бизнеса. Как и многие другие компании, ваш бизнес не может работать без вашей критически важной инфраструктуры, поэтому в компаниях, работающих в настоящее время 24 × 7, это означает, что много тепла и шума генерируется в ограниченном пространстве, которое специально не предназначено для поддержки такого рода среды. Это звучит эффективно?

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

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



Все дело в безопасности вашей критической ИТ-инфраструктуры
Безопасность и соблюдение требований стали серьезной проблемой и центром затрат для многих организаций. В настоящее время данные являются наиболее ценным корпоративным ресурсом, и, когда речь заходит о безопасности, ни одна локальная среда не может сравниться с протоколами безопасности 24 x 7 x 365, развернутыми оператором центра совместного размещения большого радиуса действия.

Исследования IBM Security показывают, что глобальная средняя стоимость взлома данных составляет 3,86 миллиона долларов, что на 6,4% больше, чем в предыдущем году. Средняя глобальная стоимость каждой утерянной или украденной записи конфиденциальной и конфиденциальной информации также возросла и в настоящее время составляет 148 долларов США за запись. Это огромные расходы.

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



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

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

Можете ли вы позволить себе оставаться на месте с вашей критически важной ИТ-инфраструктурой?
Ваши клиенты, партнеры и сотрудники, которые в настоящее время ожидают постоянный уровень обслуживания, а также беспроблемное и беспроблемное взаимодействие, можете ли вы позволить себе нести затраты и сложность обслуживания локального центра обработки данных?

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

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

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

Специалисты Linxdatacenter проводят работы по развертыванию и настройке сетевой инфраструктуры. Дежурные инженеры осуществляют круглосуточную поддержку и мониторинг сети, выявляют и оперативно устраняют ошибки в работе инфраструктуры, в том числе на удаленных площадках, где физически располагается оборудование. Компаниям с крупной ИТ-инфраструктурой, для которых критична отказоустойчивость сети и необходима собственная политика маршрутизации, Linxdatacenter предлагает сервис по созданию и управлению клиентской автономной системой. В комплекс услуг входят регистрация LIR, приобретение автономной системы и блока IP-адресов, настройка протоколов маршрутизации и управление трафиком.

Для клиентов ЦОД, которым важна бесперебойная связь, компания реализовала решение по резервированию сетевой инфраструктуры. Стабильность связи обеспечивается за счет резервирования маршрутизаторов средствами протокола VRRP, а также резервирования кроссировок и сетевого оборудования ЦОД. Еще одним новым сервисом стал резервный удаленный доступ к сетевому оборудованию. Услуга осуществляется через постоянное подключение COM-порта к консольному серверу Linxdatacenter, с возможностью переключения между единицами оборудования. Клиент получает удаленный доступ к одному или нескольким независимым последовательным портам через соединение по протоколу TCP/IP. К преимуществам сервисам можно отнести быструю настройку сети, независимый доступ к консоли при полной потере управления, возможность восстановления конфигурации сети из любой точки, удобство управления как с помощью Telnet/SSH, так и сторонних клиентов. Для повышения уровня безопасности услуги в нее встроены меры защиты: дополнительная аутентификация при удаленном подключении и гибкое разграничение прав доступа по ролям пользователей.

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

комментирует Андрей Перекрест, руководитель ЦОД Linxdatacenter Москва

Краткая справка о Linxdatacenter
Linxdatacenter (штаб-квартира в Амстердаме, Нидерланды) – один из лидеров международного рынка высокотехнологичных ИТ-решений для бизнеса. География предоставления услуг Linxdatacenter охватывает рынки Центральной и Восточной Европы, России, Азии и Скандинавии. Компания предоставляет облачные решения и сервисы в области хранения данных в собственных дата-центрах уровня TIER III в Москве и Санкт-Петербурге, а также на базе партнерских дата-центров в Варшаве, Шанхае и Гонконге. Портфолио Linxdatacenter включает услугу частного доступа к глобальным облачным сервисам, таким как Amazon Web Services и Google Cloud Platform.
Дата-центры компании имеют сертификацию ISO 27001, ISO 9001, PСI DSS, SAP Cloud and Infrastructure и соответствуют стандарту Management & Operations Stamp of Approval (Uptime Institute). Опыт работы компании составляет более 18 лет. Подробнее о решениях Linxdatacenter на сайте ru.linxdatacenter.com/

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

В этот раз «под микроскопом» оказались два поколения 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%.

Не прошло и два года с момента анонса, как 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

1dedic.ru/articles/pamyatka-klienta

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-адресами, можно приступать к настройке.

• Настраиваем VLAN на серверах Linux
• Настраиваем VLAN на серверах Windows

Подробнее
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 июня с 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!
Хорошо, это может быть не так интересно для всех, но нашей помощи свежа и наша гордость чиста. Мы считаем, что мы построили что-то особенное!

Давайте посмотрим правде в глаза, в то время как наш Free DNS является лучшим, что было трудно смотреть на него. С редизайн нашего интерфейса управления DNS, мы решили добавить некоторые новые функции, чтобы сделать управление DNS простым:

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

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

В мае мы успешно произвели работы по замене коммутатора на 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;
• Перенос основного коммутатора;
• Установка нового коммутатора;
• Переключение внешних портов на новый коммутатор;
• Организация двух воздуховодов для нового коммутатора;
• Упорядоченное переключение серверов;
• Осуществление процедур по наведению порядка и проверке корректности работы коммутатора. Замена коммутатора позволила увеличить скорость передачи данных на всех нодах.