С чего начинать тестирование двухюнитовых серверов с 16 планками U-DIMM и 24 хардами в Linux?
Всем утро доброе, товарищи!!!
Столкнулась с такими сложностями, но сначала предисловие:
На данный момент занимаюсь тестированием одноюнитовых серверов на intel Atom/Xeon от 2 до 8 ядер с поддержкой Гипертрейдинга в OS Ubuntu 20.04.3. Ничего сложного, стандартный набор команд для проверки работы систем железа (процессор, память, порты, скорость передачи данных, нагрузочные тесты через "stress")
Но!
Так случилось, что пригласили на работу в молодой старт-ап для тестирования серверов. Выхожу уже на след. неделе.
Но по спустя время выяснилось, что производят они не просто сервера, а целые комплексы (шкафы, схд), где суммарное количество ядер процессора доходит до 40(!) на одной только машине.
Возник естественный вопрос: КАК ЭТОГО ЗВЕРЯ ПРИРУЧИТЬ?
Главная проблема в том, что единственным человеком, кто знаком с пингвиньей системой - это я. По этому обратиться за помощью не к кому. Вот я и пришла к ВАМ
И так вопросы:
1. Софт
Убунту я использовать буду первое время, но основная просьба - найти опенсорсную OS, желательно отечественную.
Астру даже не рассматриваю, хотя она и сертифицирована, но я так с ней намучилась.... Думала о FX-RTOSe, но ребята говорят, что открытая версия - сильно урезана и вряд-ли подойдет для моих целей. В общем, что использовать - вопрос.
2. Процессор
Не представляю как гонять 4 проца, да еще и с 40 ядрами одновременно. Не уверена, что утилита stress-ng способна разогнать 4 проца разом, и что эта вся красота не уйдет в дичайший троттлинг, даже при условии активного охлаждения. Если у кого-то будут идеи - буду очень благодарна)
3. Память и диски
В машинах стоит от 12 до 24 хардов в рейд массиве. При том не известно (пока что) физически они собраны (через плату RAID) или программно. С СХД дел не имела, тестила максимум физический рейд из 2 хардов. Как проверить сразу 20 - не представляю.
Что касается памяти тут отдельная история, поступила жалоба, что U-DIMMы работают только при полной сборке (все 16), либо подключенные последовательно (с1 по 4 место например), но подключая в 1,3,7,12(например) места некоторые планки не определяются, либо сервер работает не корректно (не запускается, не стартует). В чем проблема не знаю, может быть гений радиоэлектроники сможет подсказать? Вдруг проблема в разводке на плате или еще что-то.
4. Методология тестирования
Ранее работала по данной схеме:
♦Проверка линка и работы сетевых интерфейсов (скорость портов, правильность МАС-адресов, назначенные динамические IP-адреса)
♦Проверка памяти, корбута и системы (dmidecode)
♦Вывод имеющихся ошибок грепом
♦Проверка работы рейд-контроллера (0,1,PM), установка на диски OS, загрузка с них, имитация аварийного отключения, восстановление
♦Длительное стресс-тестирование
Искала методологию тестирования больших машин (сервера и схд) на процессоре Intel в Linux,но ничего не нашла. Если кто-то что-то видел или знает, поделитесь пожалуйста опытом, ссылками, всем буду примного благодарна♥
1. Используйте Debian, он бесплатен. Я бы не советовал связываться с российскими ОС, тем более для бизнеса они платные вроде как. И подороже винды))
отечественных ОС у нас нет, есть просто сертифицированная и частично проверенная))
2. Пробуйте для начала так же, возможно программа умеет в несколько потоков
3. Ну если есть рейд контроллер - тетсируйте как обычно, только с поправкой на количество дисков(например в плане скорости доступа)
если нет контроллера - просто исключите этот пункт из тестирования
По оперативки - там же слоты привязанны к конкретному процессору, надо смотреть что в инструкции по сборке указано, какие слоты могут работать по отдельности
До документации еще не дошла, тк пока дорабатываю на старой работе.
Про связь оператива- проц знаю, единственное не имела дел с машинами где есть несколько процессоров, по этому не знаю как связываются порты с ними (да и представления не имею). надо будет ознакомиться. Единственное, насколько я поняла платы они разрабатывают самостоятельно.. По этому там и не исключена какая-то ошибка. Спасибо)
Melkij Спасибо за инфу.
Проблема не в ядерности (хотя она и пугает немного, ведь ранее с подобными процами я не работала и их специфика мне не известна), а в нескольких процессорах на одной плате.
Я работаю с однопроцессорными платформами по этому мне не понятно их взаимодействие и общение друг с другом в таких условиях. Не знаю, имеют ли стоковые утилиты поддержку подобного. ОТ этого и возник вопрос, что бы когда я дошла до документации у меня уже было хотя бы представление, что с этим делать, и могу ли я тестировать их так же, как и стандартные машины.
Да, работаю с серверами пол года. Но пока не ас и не супер специалист, пока развиваюсь и учусь.
CPU(s): 256
On-line CPU(s) list: 0-255
Thread(s) per core: 2
Core(s) per socket: 64
Socket(s): 2
Я не понял проблематику ситуации. 40 ядер, несколько сотен гигов RAM да пара десятков дисков - средняя железка, какие там у вас специфические проблемы такие? 40 ядер нынче не проблема даже одним сокетом получить.
Что касается памяти тут отдельная история, поступила жалоба, что U-DIMMы работают только при полной сборке (все 16), либо подключенные последовательно (с1 по 4 место например), но подключая в 1,3,7,12(например) места некоторые планки не определяются, либо сервер работает не корректно (не запускается, не стартует).
См. документацию к материнке. Там будет описано, в каком порядке необходимо заполнять слоты. Да, это стандартное требование JEDEC для DIMM'ов, что серверных, что десктопных. Технически связано с терминаторами. Затем, после требований стандарта, идёт логика как не повесить всю имеющуюся память на один и тот же канал памяти одного и того же CPU. NUMA всё-таки.
Вы правда занимаетесь серверами?
Мне кажется (возможно что я ошибаюсь) наилучшим вариантом будет:
1. Убедить руководство что Автору темы нужен помощник (добавить штатную единицу)
2. Взять на эту должность бородатого, пузатого, в свитре с оленями админа
3. Продолжить пить смузи с руководством стартапа, а настоящий админ всё что надо сделает
Александр Фалалеев, Ошибаешься, на нынешней работе я работаю за 3-их, начиная от сборки тестовых стоек, из настройки, до непосредственного тестирования серверов. Но по скольку работаю с мелкими одноюнитовыми серверами ( по типу Adwantech и стареньких Huawei), гд есть один проц, одна оператива so-dimm либо 4 u-dimm,которые завязаны на одном проце, где массив собирается аппаратно, а не программно и из 2-х SSD SATA lll, а придется иметь дело с более сложными машинами,с 4 процессорами (к тому же более многоядерными, нежели мои 8ки), которые мне непонятно как общаются, по этому и решила спросить у людей,которые возможно имели с дело с похожими. И тестили непосредственно работу железа, а не софт..
+ у них разработка с нуля, включая мать, на которой все это завязано. Я с такой проблемой на однопроцессорном серваке не сталкивалась.
По п.3 и тротлинг.
Так в этом же и есть смысл теста, нагрузить все процы и убедиться что оно не уйдёт в дичайший тротлинг. Ведь если будет тротлить, значит тест не прошло, косяк где-то, возможно в шкафу надо переделывать охлаждение. И лучше это исправить до того как шкаф уедет к заказчику и он вдруг откажется подписывать акты приёмки и придётся посылать бригаду с болгарками монтировать доп охлаждение.
Простой
