С точки зрения ИТ, мы - небольшой магазин, и почти все наши серверы и сетевое оборудование покупаем на сером рынке - обычно через eBay. Я заинтересован в разработке более тщательного процесса тестирования, прежде чем внедрять это оборудование серого рынка в производство. Какие стресс-тесты оборудования, наборы тестов и т. Д. Рекомендуются для этого сценария?
Примечание: Что касается этого вопроса, меня не интересует обсуждение достоинств покупки нового оборудования или оборудования для серого рынка. Учитывая наш размер и бюджет, мы считаем, что покупка на сером рынке - будь то подержанное или новое оборудование - дает нам максимальную отдачу от вложенных средств. Спасибо.
Я думаю, это зависит от ваших требований к времени безотказной работы и от того, с каким уровнем «серого рынка» вы имеете дело.
Если ваши требования к времени безотказной работы высоки, то вам следует полагаться на избыточность инфраструктуры, чтобы потеря одной машины не означала потерю услуг для ваших клиентов. Купить двойной, построить избыточностьи отслеживайте свои хосты и сеть, чтобы знать, когда вам нужно что-то заменить.
Если ваши требования к времени безотказной работы не так высоки, но вам просто нужно рабочее оборудование, оцените людей, у которых вы покупаете. Не покупайте вещи, не относящиеся к DOA. Если можете, покупайте в восстановленных магазинах с гарантией не менее 90 дней, хотя год был бы неплохим, если бы вы могли себе это позволить, и убедитесь, что вы можете получить запасные части для всего, что вы покупаете, из другого источника, если оригинал закроется. .
Мы покупаем подержанное оборудование IBM в разумных количествах вместе с новым по цене $ JOB. Сейчас это все лезвия HS / LS, но в прошлом у нас было много коробок для пиццы x3 **. Как я уверен, вы знаете, есть много отличных вещей, которые можно получить от завершения договоров аренды с другими людьми и обновления оборудования. Часто даже когда остается некоторое время на гарантии производителя.
Обычно любые проблемы, которые мы наблюдаем, устраняются довольно быстро и становятся очевидными в журналах событий BladeCenter или BIOS. Их обычно можно устранить, просто запустив машину на короткий период времени и перезапустив ее.
Не так уж часто можно увидеть S / H шестерню, заполненную приводами. Когда бы мы ни делали это, их выбрасывают. Прядильные носители почти всегда являются самым слабым звеном в цепочке оборудования. Вы не знаете, возникали ли проблемы с дисками ранее или они упали при транспортировке. Диски настолько дешевы для покупки новых, что это не стоит наших хлопот.
Что касается технического вопроса, какой инструмент использовать. Поскольку кажется, что вы имеете дело только с машинами IBM, вы также можете использовать удобный и комплексный инструмент диагностики, который IBM уже добавила. Просто нажмите F2 при загрузке.
memtestp и iozone - два моих любимых.
Еще одна мысль - попытаться стандартизировать ваши системы. Постарайтесь купить такое же оборудование, которое затем можно будет использовать в качестве запасных частей, если это необходимо. Фактическое тестирование будет зависеть от имеющегося времени. Я бы попытался создать свой собственный автоматизированный (и повторяемый) набор тестов, в котором были бы задействованы все основные компоненты. ЦП, память, дисковый ввод-вывод, сетевой ввод-вывод - вот то, что я бы попытался подчеркнуть в тесте, который нужно запускать несколько раз и использовать для установки базового уровня. Каждая система, которая работала ниже этого базового уровня (на 10 или 20% ниже), должна быть повторно проверена перед развертыванием в производственной среде.
Обычно я загружаю тестируемую систему с внешнего носителя, то есть с USB-флеш-накопителя или с сетевой PXE-загрузки на ramdisk. Это позволяет мне тестировать диски разрушительным образом и создавать хорошую многоцелевую тестовую среду.
Для тестирования диска я использую разрушающий 4-х проходной тест badblocks на необработанном устройстве, например.
badblocks -vw /dev/sda
ПРИМЕЧАНИЕ: это уничтожит все данные на диске! Если у вас несколько дисков, это может вызвать дополнительную нагрузку на систему для их параллельного тестирования.
Компиляция ядра Linux считается хорошим общим тестом системы. Я запускаю один цикл компиляции на каждое ядро процессора. Настройте дерево исходного кода ядра по умолчанию и скопируйте его для каждого экземпляра. Затем в каждом случае выполните что-нибудь вроде:
while (1); do make clean && make bzImage; done
Пока идет компиляция ядра, вы можете захотеть следить за температурой процессора с помощью датчиков, например:
while (true) do sensors | grep Temp; sleep 5; done
Запустите это в течение 24 часов, и в конце у вас должна быть хорошая надежная система.
Мне нравится использовать memtest86 для тестирования подсистемы памяти. Он сообщит вам, есть ли в вашей системе неисправные модули памяти.
Для тестирования ЦП мне нравится запускать клиент Distributed.net RC5-72; это загрузит ваши процессоры до 100% обработки 72-битных ключей RSA. Если есть проблема с процессорами или связанными с ними компонентами, я думаю, они их найдут. Я позволяю ему работать так долго, как могу - помимо того, что он чертовски нагружает мои процессоры, он также увеличивает мою статистику DNETC :) Хотя, вероятно, для стресс-тестирования системы я бы запустил его как минимум за 24 часа.
Плохие блоки, как упоминалось выше, являются хорошим способом стресс-тестирования дисководов, если вы хотите их сохранить (отдельное обсуждение). Альтернативой деструктивному тесту чтения / записи, упомянутому VMBed, является неразрушающий тест чтения / записи, который оставляет данные нетронутыми.