Наверное, вы меня не поняли. Я для простоты рассматиривал только нагрузку в 16 потоков (и все цифры привёл именно для неё). И именно для неё на этой картинке из комментария внезапно наблюдается сильный рост IOPS-ов.
В приведённом документе для 16-ти потоков также видно падение IOPS-ов в вертикальном тесте (9k -> 4k). И я не вижу там нигде роста IOPS-ов при переходе от чтения к записи (при сохранений количества нод кластера и числа потоков). Поэтому и говорю: не ошибка ли в картинке.
Не понимаю, почему и в посте и у ceph на этой картинке IOPS-ы при переходе от случайного чтения к случайной записи падают в разы (107k -> 19k, 204k -> 31k, 1.5k -> 0.6k), но только у PCS на этой картинке они растут (3k -> 5k). Это не ошибка? Тогда за счет чего такой прирост?
Т.е. десять лет планировали и внедряли, не возникло мысли что что-то идёт не так? А как внедрили, обернулись — батюшки святы…
Желтизна какая-то. Перевод на русский подозрительно ориентированного англоязычного ресурса, своими словами пересказывающего немецкую газету. Мутновато какт-то.
Тоже интересно. Давно не смотрел его, а тут вот довелось чуть пощупать CFEnginev3. Особо вроде ничего не поменялось со времён CFEnginev2 — у него как был так и остался негуманоидный синтаксис и сложность внедрения. Надеюсь, хоть регулярные сегфолты в трешке починили.
После эксплуатации CFv2, осмотра chef/puppet/salt/CFv3, понравился Ansible. Реально гораздо проще начинать и продолжать. Не без недостатков конечно, но апстрим довольно вменяемый и оперативный.
Из тех, что сталкивались и можно показывать людям, всё вроде здесь. Но есть ещё свой мегапатч, который меняет кучу захардкоренных констант под конкретное применение. И как читавший этот патч и смотревший код скажу что там ещё работы непочатый край. Поэтому и не особо хочется запускать iperf.
2 FessAectan: используем свои сборки iperf2/3, одно-два коммерческих решения и несколько самописных. Код наших программистов я не читал, здоровье и так подорвано.
Тоже хотел сказать за cobbler, но опередили. Плюс, для раскатки наверное лучше была бы какая-нибудь SCM (ansible/salt/chef/puppet/etc). Поможет в дальнейшем сопровождении.
Этому нетконсолю бы ещё dot1.q-тег. Не понимаю ядерщиков с их 'netconsole is very very log level'. Если мы всё равно формируем кадр и отсылаем его в сеть, что мешает заполнить его указанным тегом…
В приведённом документе для 16-ти потоков также видно падение IOPS-ов в вертикальном тесте (9k -> 4k). И я не вижу там нигде роста IOPS-ов при переходе от чтения к записи (при сохранений количества нод кластера и числа потоков). Поэтому и говорю: не ошибка ли в картинке.
Желтизна какая-то. Перевод на русский подозрительно ориентированного англоязычного ресурса, своими словами пересказывающего немецкую газету. Мутновато какт-то.
После эксплуатации CFv2, осмотра chef/puppet/salt/CFv3, понравился Ansible. Реально гораздо проще начинать и продолжать. Не без недостатков конечно, но апстрим довольно вменяемый и оперативный.
2 FessAectan: используем свои сборки iperf2/3, одно-два коммерческих решения и несколько самописных. Код наших программистов я не читал, здоровье и так подорвано.
P.S.: на iperf3 краем глаза посмотрели, сырое.
Из аналогов знаю mf2b, но выглядит он пока сыровато.