numa bios что это
NUMизматика, NUMерология и просто о NUMA
Три Богатыря
И начнем с отрицания отрицания. То есть, посмотрим на Uniform Memory Access (Однородный доступ к памяти), известный также так SMP (Symmetric Multi Processing – Симметричная Многопроцессорная Обработка).
SMP – это архитектура, в которой процессоры соединены с общей системной памятью при помощи шины или подобного соединения)симметрично, и имеют к ней равный однородный доступ. Именно так, как показано на схеме ниже (на примере двух CPU), были устроены все многопроцессорные машины Intel, когда контроллер памяти (MCH/MGCH), больше известный как «Северный Мост» (“NorthBridge”) находился в чипсете.
Недостаток SMP очевиден — при росте числа CPU, шина становится узким местом, значительно ограничивая производительность приложений, интенсивно использующих память. Именно поэтому SMP системы почти не масштабируются, два-три десятка процессоров для них – это уже теоретический предел.
Альтернатива SMP для производительных вычислений – это MPP (Massive Parallel Processing).
MPP — архитектура, разделяющая систему на многочисленные узлы, процессоры в которых имеют доступ исключительно к локальным ресурсам. MPP прекрасно масштабируется, но не столь прекрасно программируется. А именно — не обеспечивает встроенного механизма обмена данными между узлами. То есть, реализовывать коммуникации, распределение и планировку задач на узлах должен выполняемый на MPP софт, что подходит далеко не для всех задач и их программистов.
И, наконец, NUMA (Non-Uniform Memory Access). Эта архитектура объединяет положительные черты SMP и MPP. NUMA система разделяется на множественные узлы, имеющие доступ как к своей локальной памяти, так и к памяти других узлов (логично называемой «удаленной»). Естественно, доступ к удаленной памяти оказывается гораздо медленнее, чем к локальной. Оттуда и название – «неоднородный доступ к памяти». Это – не только название, но и недостаток архитектуры NUMA, для смягчения которого может потребоваться специальная оптимизация софта, о которой — дальше.
Вот как выглядит двухсокетная NUMA система Intel Xeon (а именно там дебютировала Intel NUMA) с контроллерами памяти, интегрированными в CPU.
Процессоры здесь соединены QPI — Intel QuickPath соединением «точка-точка» с высокой пропускной способностью и низкой задержкой передачи.
На рисунке не показан кеш процессоров, но все три уровня кеш памяти, конечно же, там есть. А значит, есть и особенность NUMA, о которой необходимо сказать: NUMA, используемая в системах Intel, поддерживает когерентность кешей и разделяемой памяти (то есть, соответствие данных между кешами разных CPU), поэтому ее иногда называют ccNUMA — cache coherent NUMA. Это означает наличие специального аппаратного решения для согласования содержимого кешей, а также и памяти, когда более чем один кеш хранит одну и ту же ее часть. Конечно, такое общение кешей ухудшает общую производительность системы, но без него программировать систему с непредсказуемым текущим состоянием данных было бы крайне интересно затруднительно. Для уменьшения влияния этого эффекта, следует избегать ситуаций, когда несколько процессоров сразу работают с одним блоком памяти (не обязательно с одной переменной!). Именно так и пытаются поступить продукты, поддерживающие NUMA.
Таким образом, от железа мы плавно перешли к программному обеспечению и производительности NUMA систем.
Итак, NUMA поддерживается следующими OS:
Windows Server 2003, Windows XP 64-bit и Windows Vista – до 64 логических процессоров,
Windows 7, Windows Server 2008 R2 – полная поддержка.
Linux OS kernel: 2.6 и выше, UNIX OS — Solaris и HP-Unix.
Если говорить о базах данных, то NUMA поддерживается Oracle8i, Oracle9i, Oracle10g и Oracle11g, а также SQL Server 2005 и SQL Server 2008.
Поддержка NUMA реализована и в Java SE 6u2, JVM 1.6, а также .NET runtime на вышеупомянутых версиях Windows.
Полностью поддерживает NUMA математическая библиотека Intel – MKL.
«Поддержка NUMA» означает следующее – продукт знает о топологии NUMA машины, на которой исполняется, и пытается использовать ее максимально эффективно, то есть, организовать работу потоков так, чтобы они в полной мере использовали память своего узла (того, на котором исполняется данный поток) и минимально – чужих. Ключевое слово здесь – «пытается», так как сделать это в общем случае возможно не всегда.
Поэтому может случиться, что продукт, не поддерживающий NUMA, то есть, просто не знающий о ней, что совсем не мешает ему запускаться и исполняться на NUMA-системах, покажет не худшую производительность, чем официально поддерживающий NUMA. Пример такого продукта — знаменитая библиотека Intel Threading Building Blocks.
Именно поэтому в BIOS мультисокетных серверов с NUMA есть специальный пункт «Разрешить\запретить NUMA». Конечно же, от запрета NUMA в BIOS топология системы никак не изменится — удаленная память не приблизится. Произойдет только следующее – система не сообщит ОС и ПО о том, что она NUMA, а значит, распределение памяти и планировка потоков будут «обычными», такими как на симметричных многопроцессорных системах.
Если BIOS разрешает NUMA, то операционная система сможет узнать о конфигурации NUMA узлов из System Resource Affinity Table (SRAT) в Advanced Configuration and Power Interface (ACPI). Приложения могут получить такую информацию, используя библиотеку libnuma в Linux, а сами понимаете, на каких системах — Windows NUMA interface.
Эта информация – начало поддержки NUMA вашим приложением. За ним должна следовать непосредственно попытка максимально эффективно использовать NUMA. Общие слова на эту тему уже сказаны, для дальнейших пояснений перейду к частному примеру.
Допустим, вы выделяете память при помощи malloc. Если дело происходит в Linux, то malloc только резервирует память, а ее физическое выделение происходит только при фактическом обращении к данной памяти. В этом случае память автоматически выделится на том узле, который ее и использует, что очень хорошо для NUMA. В Windows же malloc работает по-другому, он выделяет физическую память непосредственно при аллоцировании, то есть, на узле выделяющего память потока. Поэтому она вполне может оказаться удаленной для других потоков, ее использующих. Но есть в Windows и дружественное к NUMA выделение памяти. Это VirtualAlloc, который может работать точно также, как malloc в Linux. Еще более продвинутый вариант — VirtualAllocExNuma из Windows NUMA API.
Следующий простой пример, использующий OpenMP,
можно подружить с NUMA, обеспечив инициализацию данных каждым потоком, вызывающую соответствующую привязку физической памяти к использующему ее узлу:
Отдельным пунктом здесь надо упомянуть Affinity — принудительную привязку потоков к конкретным процессорам, предотвращающую возможную переброску операционной системой потоков между процессорами и могущую вызвать потенциальный «отрыв» потоков от своей используемой локальной памяти.
Для установки Affinity имеются соответствующие API как в Linux, так и в Windows ( стандартный Windows API, и NUMA WinAPI). Также функциональность для установки привязки присутствуют во многих параллельных библиотеках (например, в показанном выше примере OpenMP за это отвечает переменная окружения KMP_AFFINITY ).
Но надо понимать, что во-первых, affinity срабатывает не всегда (для системы это, скорее, намек, чем приказ), а во-вторых, положительный эффект от установки Affinity будет только в том случае, когда вы полностью контролируете систему, то есть, на ней работает исключительно ваше приложение, а сама ОС не сильно нагружает систему. Если же, как это чаще всего бывает, приложений несколько, причем, они интенсивно используют CPU и память, пытаясь при этом привязаться к одному процессору, ничего не зная друг о друге, да и ОС конкурирует за те же ресурсы, то от использования Affinity может быть больше вреда, чем пользы
Производительность.
1.4 раза), пропускная способность локальной памяти превосходит удаленную на 40% ”.
На вашей реальной системе эти приблизительные данные могут быть получены при помощи бесплатной утилиты Microsoft Sysinternals — CoreInfo, оценивающей относительную «стоимость» доступа к памяти разных узлов NUMA. Результат, конечно, сильно приблизительный, но некоторые выводы сделать позовляет.
Пример результата Coreinfo:
Как видите, разница составляет всего чуть более 5%! Результат приятно удивительный. И это – случай максимальной разницы, достигаемый при 32 одновременно работающих потоках с запросами (при другом количестве потоков разница еще меньше).
Так нужно ли оптимизировать для NUMA? Зайду издалека. Хотя у меня нет времени убираться дома, зато есть время читать советы по уборке :). И один из полезных, виденных мной советов такой — чтобы меньше убираться, надо избежать потенциального беспорядка, для чего старайтесь хранить все вещи как можно ближе к месту их использования.
Теперь замените «вещи» на «данные», а «квартиру» на «программу» и увидите один из способов достичь порядка в ваших программах. Но это как раз и будет NUMA-оптимизация, о которой вы сейчас и прочли.
Numa BIOS
Numa BIOS – российская БСВВ, разработана в полном соответствии со стандартом UEFI и заменяет стандартный BIOS.
Уникальное доверенное отечественное микропрограммное обеспечение, единственная полноценная альтернатива иностранным BIOS для средств вычислительной техники построенных на платформах Intel и AMD под архитектуру x86/x64.
«Производственная компания «Аквариус» – ведущий российский разработчик, производитель и поставщик компьютерной техники и ИТ-решений для государственных и корпоративных заказчиков.
Под брендом Aquarius компания производит серверные системы и системы хранения данных, широкий спектр клиентских устройств (ноутбуки, моноблоки, персональные компьютеры, рабочие станции, тонкие клиенты, информационные терминалы), а также специализированные ИТ-решения по информационной безопасности и отраслевые ИТ-решения для здравоохранения и образования.
ДЕПО Компьютерс — российский разработчик и производитель вычислительной техники и комплексных решений с 25-летним опытом построения сложных информационно-коммуникационных систем и глубокими компетенциями в области системной интеграции. Сеть из более чем 200 интеграционно-сервисных центров оказывает услуги по внедрению, пуско-наладке и сервисному обслуживанию решений ДЕПО Компьютерс на всей территории РФ. Компания проектирует и разрабатывает уникальные решения под требования российских заказчиков. ДЕПО Компьютерс работает в России, предлагая заказчикам надежную и доступную по цене отечественную альтернативу импортным решениям.
ICL Техно — российский производитель вычислительной техники, ориентированный на создание и производствонового высокотехнологичного оборудования с высокой степенью локализации для автоматизации бизнес-процессов во всех отраслях экономики. ICL Техно входит в группу компаний ICL, работающую в ИТ-бизнесе более 29 лет. Собственные производственные мощности компании обеспечивают возможность изготовления до 300 000 изделий в год. Под брендом ICL завод выпускает настольные и мобильные системы, серверы, системы хранения данных, интерактивные панели, инфоматы, а также отраслевые решения для здравоохранения, образования, силовых структур и сектора ритейл.
Группа Компаний ТОНК специализируется на производстве компьютерных платформ для организации рабочих мест в информационных системах с терминальным доступом или с использованием технологий виртуализации.
Сегодня ТОНК занимает лидирующую позицию в производстве и дистрибуции тонких клиентов, Windows и Linux терминалов, компьютеров с пассивным охлаждением, терминальных систем и предлагает широкий ассортимент тонких клиентов и компьютеров с полным отсутствием каких-либо движущихся частей, специализированных вычислительных систем.
Компания Lanner предлагает спектр сетевых устройств и прикладных вычислительных платформ для системных интеграторов, сервис-провайдеров и разработчиков приложений, работающих в различных отраслях: телекоммуникации и организация сетей, транспорт, промышленная автоматизация, энергетика и т.д. Это предложение включает в себя подготовку индивидуального проекта и производственные услуги наряду с интеграцией аппаратного и программного обеспечения, чтобы предоставить конечным пользователям готовые комплексные системы.
Numa BIOS
Содержание
2021: Адаптация Numa BIOS для ноутбуков RAYbook
ICL Техно 10 февраля 2021 года сообщил, что совместно с НумаТех подписали соглашение о технологическом партнерстве.
Компании начали сотрудничество в области разработки и производства средств вычислительной техники с высокой степенью локализации. В планах – использование совместных компетенций для создания как отдельных продуктов, так и комплексных ИТ-решений, отвечающих требованиям по безопасности информации.
Стоит отметить, что для компьютерного и серверного оборудования производства ICL Техно, где в качестве базовой системы ввода-вывода будет использоваться Numa BIOS, будет доступна возможность использования модуля доверенной загрузки Numa Arce, сертифицированного ФСТЭК России. Numa Arce реализован в виде EFI приложения и может применяться для защиты информации в государственных информационных системах, информационных системах персональных данных, на объектах критической информационной инфраструктуры, а также в автоматизированных системах управления технологическими процессами.
Отдельные исполнения серверных аппаратных платформ ICL Техно будут производиться с предустановленным доверенным Numa BIOS, позволяющим использовать оборудование в составе решений, к которым предъявляются требования по безопасности информации (ИСПДн, ГИС, КИИ), а также в качестве основы для создания программно-технических средства защиты информации. Кроме того, компании планируют проводить совместные работы по созданию комплексных решений, базирующихся на использовании доверенной системы серверной виртуализации Numa vServer, предназначенных для построения виртуальных инфраструктур, масштабирующихся до геораспределённого частного или гибридного облака.
2020: Завершение разработки отечественной базовой системы ввода-вывода Numa BIOS для DEPO Neos
9 октября 2020 года компания «НумаТех» сообщила о завершении разработки отечественной базовой системы ввода-вывода Numa BIOS, предназначенной для оснащения персональных устройств линейки DEPO Neos производства «ДЕПО Компьютерс». Данная разработка является результатом технологического партнерства российского производителя вычислительной техники и российского разработчика системного, специализированного программного обеспечения и средств защиты информации.
По информации компании, соглашение о сотрудничестве и технологическом партнерстве между российскими компаниями «ДЕПО Компьютерс» и «НумаТех» предполагает использование научно-технического, технологического и производственного потенциала сторон для создания российской вычислительной техники, соответствующей критериям импортозамещения.
На октябрь 2020 года линейка автоматизированных рабочих мест DEPO Пересвет и линейка моноблоков DEPO Neos внесены в реестр отечественной вычислительной техники, который опубликован на сайте Минпромторга РФ. Данные персональные устройства производятся в России на базе отечественной материнской платы ДЕПО.
Для повышения уровня информационной безопасности и расширения возможностей линейки персональных устройств линейки DEPO Neos совместно с компанией «НумаТех» проведены работы по разработке и отладке специального исполнения российской базовой системы ввода-вывода Numa BIOS для материнской платы ДЕПО.
Программное обеспечение Numa BIOS для «ДЕПО Компьютерс» создано по специально разработанному техническому заданию и реализует все возможности материнской платы ДЕПО, обеспечивает поддержку отечественных операционных систем и совместимость с российскими аппаратными идентификаторами в форм-факторе смарт-карт и USB-токенов. Поскольку исходные коды Numa BIOS принадлежат российской компании «НумаТех», персональные устройства DEPO Neos с данным вариантом базовой системы ввода-вывода полностью готовы к сертификации по требованиям информационной безопасности в соответствии с действующей в России нормативно-правовой базой, в том числе в соответствии с требованиями российских силовых министерств и ведомств.
Numa BIOS входит в Реестр отечественного программного обеспечения (реестр опубликован на сайте Минкомсвязи РФ). Базовая система ввода-вывода, разработанная компанией НумаТех, полностью соответствует спецификации UEFI 2.7.
Помимо операционных систем семейства Windows и свободно-распространяемых дистрибутивов Linux, Numa BIOS обеспечивает загрузку и полноценное функционирование отечественных операционных систем специального назначения. Протестирована работа ОС Astra Linus Special Edition (релиз «Смоленск») на материнской плате ДЕПО с Numa BIOS. Являясь отечественной альтернативой BIOS иностранного производства, Numa BIOS делает возможным использование персональных устройств DEPO Neos российскими заказчиками.
Для заказчиков, предъявляющих расширенные требования к информационной безопасности, возможна комплектация персональных устройств DEPO доверенным вариантом Numa BIOS, сертифицированным ФСТЭК России по 4 уровню доверия. Кроме этого, возможна установка программного модуля доверенной загрузки Numa Arce. Программный модуль Numa Arce соответствует уровню загрузочной записи по классификации ФСТЭК России и может применяться для защиты конфиденциальной информации в государственных информационных системах, объектах критической информационной инфраструктуры и автоматизированных системах управления технологическими процессами. В отличие от АПМДЗ, программный модуль доверенной загрузки, встроенный в микропрограммное обеспечение персонального устройства, нельзя извлечь в процессе эксплуатации устройства. Кроме этого, в Numa Arce реализованы механизмы защиты от несанкционированного отключения и блокировки модуля. Возможностью программного модуля доверенной загрузки является отсутствие необходимости выделения отдельного слота для установки аппаратной части. Это на октябрь 2020 года актуально для мобильных устройств/ультратонких ноутбуков (где нет места для размещения классических АПМДЗ) и для серверного оборудования.
Сотрудничество компаний «ДЕПО Компьютерс» и «НумаТех» на октябрь 2020 года продолжается. До конца 2020 года планируется оснащение базовой системой ввода-вывода Numa BIOS еще как минимум 3-х материнских плат ДЕПО для персональных устройств и для серверного оборудования (серверов и систем хранения данных).
В перспективе с использованием технологий и разработок «НумаТех» в области доверенной виртуализации планируется создание комплексного решения для развертывания защищенных ЦОД на базе серверного оборудования ДЕПО Компьютерс российского производства. В основе такого решения будет использоваться доверенная система серверной виртуализации Numa vServer, разработанная с учетом требований по безопасности информации и предназначенная для создания защищенной виртуальной инфраструктуры, масштабируемой вплоть до геораспределённого частного или гибридного облака.
Кроме этого, планируется разработка аппаратно-программного межсетевого экрана в виде отдельного устройства. К таким устройствам в соответствии с Требованиями ФСТЭК России предъявляются повышенные требования по безопасности. Наличие у российской компании исходных кодов ПО позволит пройти проверку и получить сертификат ФСТЭК России на разрабатываемый межсетевой экран. [1]
NUMA и что про него знает vSphere?
Я думаю, многие уже успели заглянуть и прочитать эту статью на английском в моем блоге, но для тех кому все таки комфортней читать на родном языке, нежели иностранном (как сказали бы на dirty.ru – на анти-монгольском), я перевожу очередную свою статью.
Вы уже наверняка знаете, что NUMA это неравномерный доступ к памяти. В настоящий момент эта технология представлена в процессорах Intel Nehalem и AMD Opteron. Честно говоря, я, как практикующий по большей части сетевик, всегда был уверен, что все процессоры равномерно борются за доступ к памяти между собой, однако в случае с NUMA процессорами мое представление сильно устарело.
Приблизительно так это выглядело до появления нового поколения процессеров.
В новой же архитектуре каждый процессорный сокет имеет прямой доступ только к определенным слотам памяти и образует NUMA узел. То есть при 4 процессорах и 64 Гбайт памяти у вас будет 4 NUMA узла, каждый с 16 Гбайт памяти.
Насколько я понял, новый подход к распределению доступа к памяти был изобретен в силу того, что современные сервера настолько напичканы процессорами и памятью, что становится технологически и экономически невыгодно обеспечивать доступ к памяти через единственную общую шину. Что в свою очередь может вести к соперничеству за полосу пропускания между процессорами, ну и к более низкой масштабируемости производительности самих серверов. Новый подход привносит 2 новых понятия – Локальная память и Удаленная память. В то время как к локальной памяти процессор обращается напрямую, то к Удаленной памяти ему приходится обращаться старым дедовским методом, через общую шину, что означает более высокую задержку. Это также означает, что для эффективного использования новой архитектуры наша ОС понимать, что она работает на NUMA узле и правильно управлять своими проложениями/процессами, иначе ОС просто рискует оказаться в ситуации, когда приложение исполняется на процессоре одного узла, в то время как его (приложения) адресное пространство памяти располагается на другом узле. Быстрый поиск показал, что NUMA архитектура поддерживается Майкрософт начиная с Windows 2003 и Vmware – как минимум с ESX Server 2.
Не уверен, что в GUI как то можно увидеть данные NUMA узла, но определенно это можно посмотреть в esxtop.
Итак, тут мы можем наблюдать, что в нашем сервере 2 NUMA узла, и что в каждом их них 48 Гбайт памяти. Вот этот документ говорит, что первое значение означает количество локальной памяти в NUMA узле, а второе, в скобочках – количество свободной памяти. Однако, пару раз на своих продакшн серверах я наблюдал второе значение выше, чем первое, и никакого объяснения этому найти не смог.
Итак, как только ESX сервер обнаруживает, что он работает на сервере с NUMA архитектурой, он незамедлительно включает NUMA планировщик, который в свою очередь заботится о виртуальных машинах и о том, чтобы все vCPU каждой машины находились в пределах одного NUMA узла. В предыдущих версиях ESX (до 4.1) для эффективной работы на NUMA системах максимальное количество vCPU виртуальной машины всегда ограничивалось количеством ядер на одном процессоре. Иначе NUMA планировщик просто игнорировал эту ВМ и vCPU равномерно распределялись поверх всех доступных ядер. Однако в ESX 4.1 была представлена новая технология, называемая Wide VM. Она позволяет нам назначать в ВМ большее количество vCPU, чем ядер на процессоре. Согласно Vmware документу планировщик разбивает нашу «широкую виртуальную машину» на несколько NUMA клиентов и затем уже каждый NUMA клиент обрабатывается по стандартной схеме, в пределах одного NUMA узла. Однако, память все таки будет разрозненной между выбранными NUMA узлами этой Wide VM, на которых работают vCPU виртуальной машины. Это происходит потому, что предсказать к какому участку памяти обратится тот или иной vCPU NUMA клиент практически невозможно. Несмотря на это, Wide VM все равно предоставляют существенно улучшенный механизм доступа к памяти по сравнению со стандартным «размазыванием» виртуальной машины поверх всех NUMA узлов.
Еще одна замечательная особенность NUMA планировщика это то, что он не только решает где расположить виртуальную машину при ее запуске, но и постоянно следит за ее соотношением локальной и удаленной памяти. И если это значение уходит ниже порога (по неподтвержденной инфо – 80%), то планировщик начинает мигрировать ВМ в другой NUMA узел. Более того ESX будет контролировать скорость миграции чтобы избежать излишней загруженности общей шины, через которую общаются все NUMA узлы.
Стоит также отметить, что при установке в памяти сервер вы должны уставновить память в правильные слоты, т.к. за распределение памяти между NUMA узлами отвечает не NUMA планировщик, а именно физическая архитектура сервера.
Ну и напоследок, немного полезной информации, которую вы можете подчерпнуть из esxtop.
Краткое описание значений:
NHN Номер NUMA узла
NMIG Количество миграций виртуальной машины между NUMA узлами
NMREM Количество удаленной памяти, используемой ВМ
NLMEM Количество локальной памяти, используемой ВМ
N&L Процентное соотношение между локальной и удаленной памятью
GST_ND(X) Количество выделенной памяти для ВМ на узле X
OVD_ND(X) Количество памяти потраченной на накладные расходы на узле X
Хотелось бы отметить, что как обычно вся эта статья всего лишь компиляция того, что мне показалось интересным из прочитанного за последнее время в блогах таких товарищей как Frank Denneman и Duncan Epping, а также официальных документов Vmware.