Как стать автором
Обновить
25
0

Пользователь

Отправить сообщение
8 дисков сливающихся с 4-мя — это RAID10 из 8 дисков в degraded mode (с вытащенным одним диском) и RAID0 из четырех. Вполне логичное поведение. Enclosure нет как явления — 8 дисков висят напрямую на контроллере.
А вообще это 5 лет назад, контроллеры тогда только начали получать мощные процессоры и 800 МБ/с для большинства были в принципе максимумом пропускной способности. Поводов для слез и без того хватало: таких или таких. Сейчас, в целом, поведение контроллеров лучше, но все равно «сперва проверь, а потом ставь в работу» (а почитать и вовсе негде).

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

Немножко пруфов, простите, что 5-летней давности, блоки массивов везде по 64 кБ, смотреть на RAID10, и размер блоков запросов на чтение:

— линейное чтение, глубина очереди — 4 запроса:
img.fcenter.ru/imgmat/article/hdd/Areca_ARC_1680ix_16/138933.png

— мультипоточное чтение, глубина очереди 1 запрос, размер блока запроса 64 кБ, стоит обратить внимание на скорость одного потока чтения:
img.fcenter.ru/imgmat/article/hdd/Areca_ARC_1680ix_16/138921.png

— ну и файлики погонять можно:
img.fcenter.ru/imgmat/article/hdd/Areca_ARC_1680ix_16/138904.png

— Другой вопрос, что предсказывать поведение контроллеров невозможно, да и востребованность всего этого в современном окружении невелика.

С уважением, SV
Cisco, Juniper, Alcatel-Lucent, Brocade, H3C, Huawei, ZTE — сколько угодно роутеров на любой вкус и цвет.
BRAS — кому он такой нужен?
Да можно собирать подо всё, что угодно, никто не спорит.
Но зачем тянуть 2 ветки разработки вместо одной?
Коммутатор делится на control plane (управляющая часть) и data plane (коммутирующая часть).
Наиболее удобная аналогия — коммутирующая часть выступает для управляющей устройством на PCIe шине, как GPU либо Xeon Phi.

Связь между ними — хорошо, если PCIe 2.0 x2 и гигабит, вопрос направления каких-либо потоков вообще не стоит.
Нужна управлялка только для программирования матрицы правилами + внешнего софта для оркестровки/автоматизации процесса.
Как появились коммутаторы 10G на Freescale P2020, так и в 100G можно поставить его же.
Атомы пришли в коммутаторы позже, но и они не меняются.
Оркестровка OpenStack, NFV продукты, автоматизация (Chef и т.д.), агенты sFlow.
Мало ли чего ещё захочется поставить.

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

Будут у нас х86 серверы и PPC коммутаторы — так уже не сделать.
ARM не будет лучше по потреблению, а единый репозиторий софта гораздо удобней.
Можно поставить 8-ядерный атом, благо ничего менять не надо.
Можно поставить 2-х ядерный Атом.
Было бы желание и объём.
>Настолько? Не ну если на ruby писать то конечно и такого процессора будет мало.

Нет границ у таланта индусокодеров!

>Atom вынули, MIPS, ARM поставили?

Практически.

Плата с красным тексталитом — «серверная» часть: впаянный процессор, RAM, флеш.

hsto.org/getpro/habr/post_images/404/0b9/1c0/4040b91c057566d811980065feb4dcd0.jpg
>С моей точки зрения ставить туда тогда 4 ядерный Atom с 8 гигабайтами памяти под такую задачу несколько избыточно.

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

Собственно, архитектуру процессора можно подобрать под конкретного заказчика, если он уже имеет широкомасштабную развернутую структуру. Оно же все реализуется на дочерних платах, как завещает OCP, и пророк его Facebook.
Можно, конечно. Только матрица сама себе правил работы с трафиком не задаст.
>В Linux это никогда проблемой особой не было. А вот стоимость при сравнимых характеристиках может решать, так-как сравнимый даже с Atom MIPS/PowerPC будет стоить несколько дороже.

Вопрос в стоимости адаптации.
А разница стоимости x86/MIPS/Power несущественна от слова вообще.

>Т.е. пакеты в сетевую ОС нельзя внутрь отдать от слова никак?
На скоростях потока в матрице? Да. Там вся матрица висит на шине PCIe, по которой получает управляющие команды и отдает те данные, которые обучена отдавать. Собственно, вышеупомянутый Broadview введен Boradcom'ом как раз для расширения возможностей работы с трафиком на уровне мониторинга и анализа.

>Более того установленный процессор 10GbE имеет риск не прожевать.
Смотрите чуть ниже. Если нужно именно «жевать» трафик, то для этого сейчас принято ставить специализированные программируемые NPU.
32 порта х 100 GbE — это физические возможности коммутатора, которые реализованы на коммутационной матрице. Если вы собираетесь выводить поток из нее на обработку процессором — думайте, как вы их туда доставите.

Что же касается производительности x86… ну примерно так:
«Under the tests conducted by SDNCentral testing lab partners, the Brocade Vyatta 5600 vRouter platform ran on a mid-range, Intel Xeon server platform with dual 10-core Xeon processors (E5-2670v2 @ 2.50GHz). The tests measured L3 forwarding for a dual-socket CPU compute node with an aggregate system performance of 70 million packets per second and 80Gbps rates over a wide set of IP conditions – performance was comparable to many traditional hardware appliances.»

Поэтому перестаньте рассчитывать на то, что вы что-то успеете сделать х86-процессором с трафиком такого уровня.
А через что вы собираетесь передавать поток в три терабита в процессор?

Про производительность процессоров можно поговорить отдельно.
Это правильное перефразирование. :)
Atom используется потому, что это это архитектура x86, что упрощает перенос собственных дополнительных пакетов в среду сетевой ОС. Альтернативой являются процессоры на архитектурах MIPS и PowerPC.

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

Одиночный порт 100GbE практически полностью выедает пропускную способность PCIe x16 v3, «запихать» поток с 32 портов в процессор крайне сложно. Да и возможностей его, мягко говоря, будет несколько недостаточно.
Аргументируйте, пожалуйста.
Хех, столько лет никто не замечал опечатки. Поправили.
И всё бы было хорошо, если бы в середине проекта медикам из Краснодара не пришлось столкнуться с недобросовестным поставщиком.

Поставщик оказался настолько «недобросовестным», что по итогам борьбы с чиновниками возбуждено уголовное дело по ч. 1 ст. 286 УК РФ в отношении заместителя министра здравоохранения края.

А всё потому, что желание попилить 50% бюджета в свою пользу вредно для здоровья.
Конечно дадим, с тех пор 7.2К диски немного подросли.
Вы какой размер блока брали?

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность