Comments 17
Очень компактно и познавательно!
А есть ли какая-то статистика, насколько именно Soft iSCSI Initiator нагружает CPU, может есть примеры с конкретной нагрузкой и железом?
А есть ли какая-то статистика, насколько именно Soft iSCSI Initiator нагружает CPU, может есть примеры с конкретной нагрузкой и железом?
Существует по-сути три типа подключения по iSCSI:
Следующие возможности аппаратного ускорения работы сетевого адаптера (TOE NIC) могут снизить нагрузку на CPU хоста:
Обратите внимание, что не все сетевые адаптеры с TOE поддерживают все перечисленные функции.
Аппаратные HBA адаптеры для iSCSI, к вышеперечисленному, берут обработку ещё и четвертого уровмя модели OSI, они собственно аппаратно обрабатывают сам протокол iSCSI.
В эру многопроцессорности и высоких скоростей CPU появляется большое множество вариантов сравнения. Так к примеру некоторые HBA адаптеры построены на базе обычного x86 CPU. Настройки, наличие или отсутствие каких-то функций, к примеру DCB или включение функции Jumbo Frames в Software и iSCSI HBA могут существенно влиять на результыты нагрузки CPU.
Другими словами проще взять и проверить нагрузку самому, так как в вашем случае с вашим оборудованием, разница между какими-то статистическими данными может оказаться существенная. Для этого вы можете восспользоваться утилитами по генерации нагрузки, к примеру IOMeter.
К примеру, на сервере с двумя quad-core Intel® Xeon® E5405 процессорами с частотой 2.0 GHz, 16 GB памяти и установленным
- Чистый Software Initiator
- Software Initiator c TOE
- iSCSI HBA
Следующие возможности аппаратного ускорения работы сетевого адаптера (TOE NIC) могут снизить нагрузку на CPU хоста:
- Receive Side Scaling (RSS)
- TCP Chimney Offload
- Jumbo Frames
- Large Send Offload
Обратите внимание, что не все сетевые адаптеры с TOE поддерживают все перечисленные функции.
Аппаратные HBA адаптеры для iSCSI, к вышеперечисленному, берут обработку ещё и четвертого уровмя модели OSI, они собственно аппаратно обрабатывают сам протокол iSCSI.
В эру многопроцессорности и высоких скоростей CPU появляется большое множество вариантов сравнения. Так к примеру некоторые HBA адаптеры построены на базе обычного x86 CPU. Настройки, наличие или отсутствие каких-то функций, к примеру DCB или включение функции Jumbo Frames в Software и iSCSI HBA могут существенно влиять на результыты нагрузки CPU.
Другими словами проще взять и проверить нагрузку самому, так как в вашем случае с вашим оборудованием, разница между какими-то статистическими данными может оказаться существенная. Для этого вы можете восспользоваться утилитами по генерации нагрузки, к примеру IOMeter.
К примеру, на сервере с двумя quad-core Intel® Xeon® E5405 процессорами с частотой 2.0 GHz, 16 GB памяти и установленным
- 10GB адаптером (c TOE), можно достичь 750 MB/s при оперировании 512 KB блоками данных (видео), утилизация CPU при этом достигает 15%. В случае увеличения размера блока (до 64 KB), утилизация CPU может достигать 26%.
- 10GB адаптером (c iSCSI HBA), можно достичь 750 MB/s при оперировании 512 KB блоками данных (видео), утилизация CPU при этом достигает 1%.
- адаптером 1 GbE (с TOE), можно достичь 120 MB/s при оперировании 512 KB блоками данных (видео), утилизация CPU при этом достигает 2%.
- адаптером 1 GbE (с выключенным TOE), можно достичь 120 MB/s при оперировании 512 KB блоками данных (видео), утилизация CPU при этом достигает 3%.
- адаптером 1 GbE (с iSCSI HBA), можно достичь 110 MB/s при оперировании 512 KB блоками данных (видео), утилизация CPU при этом достигает 1%.
Почему именно iSCSI?
Потому что он хорош как для маленького ЦОД так и для большого. Для маленького не нужно покупать HBA адаптеры или специальные свичи. На начальном этапе можно задействовать обычные свичи. При росте с маленького до большого не меняется вся концепция, собственно об этом вся статья. Ну и производительность у iSCSI с 10GbE подключением ничем не хуже FC8, по крайней мере так у NetApp (у других производителей эта ситуация может быть другая). Благодаоя тому, что iSCSI не уступает по производительности и при этом живет поверх Ethernet, есть возможность клнсолидировать блочный трафик с другим трафиком на одном и том же сетевом оборудовании, таким образом есть возможность допрлнительно сэкономить. А приоритизация трафика позволит смешивать высокоприоритетный трафик с остальным без компромиса. И конечно же с NetApp FAS вы всегда вольны переключаться между iSCSI/FC/FCoE.
Универсального рецепта, конечно же нет. Каждый взвешивают интересующие именно его, «за» и «против».
Универсального рецепта, конечно же нет. Каждый взвешивают интересующие именно его, «за» и «против».
Какие альтернативы для малых ЦОД? iSCSI лучше, чем ...? Как-то вы замалчиваете эту тему.
Альтернатива блочному iSCSI это FC и FCoE.
Есть еще варианты файловых протоколов NFS и CIFS (SMB), но так как у этих протоколов нет встроенного мультипасинга и балансировки нагрузки, этот недостаток им нужно компенсировать чем-то. Такой компенсацией являются LACP с EtherChannel или лучше LACP с Multi Chassis EtherChannel. Соответственно первый вариант с файловыми протоколами и прямым подключением реализовать не удастся, для этого понадобится не любой, а свич с вышеперечисленным функционалом, на котором нужно будет еще настроить этот функционал.
Есть еще варианты файловых протоколов NFS и CIFS (SMB), но так как у этих протоколов нет встроенного мультипасинга и балансировки нагрузки, этот недостаток им нужно компенсировать чем-то. Такой компенсацией являются LACP с EtherChannel или лучше LACP с Multi Chassis EtherChannel. Соответственно первый вариант с файловыми протоколами и прямым подключением реализовать не удастся, для этого понадобится не любой, а свич с вышеперечисленным функционалом, на котором нужно будет еще настроить этот функционал.
А в плане возможностей балансировки нагрузки для малых ЦОД, к примеру с двумя серверами и 4 сетевыми линками от каждого узла, балансировка LACP будет иметь существенные недостатки, по сравнению с блочным протоколами, для приведенного примера из-за внутреннего устройства балансировки трафика.
Для того чтобы обойти эти ограничения, для малых инфраструктур, необходимо предпринимать ряд дополнительных действий.
habrahabr.ru/post/215351
Для того чтобы обойти эти ограничения, для малых инфраструктур, необходимо предпринимать ряд дополнительных действий.
habrahabr.ru/post/215351
А не будет ли для малых ЦОД внешний SAS-сторидж лучшим решением для двух серверов? Как-то FC в малых ЦОД выглядят не вполне бюджетно.
О SAS могу сказать из того, что я видел — SAS используют для подключения полок к СХД. Не смотря на то, что существуют в природе SAS свичи, во всех ЦОДах которые я видел, от миниатюрных до очень-больших, нигде не было SAS свичей. Даже JBOD полки для серверов почему то мне не попадались на глаза. По-видимому владельцы ЦОДов не рассматривают SAS свичи как замену блочным FC/FCoE/iSCSI, а также по каким-то причинам не спешат адаптировать такие дизайны в своих ЦОДах. В то же время iSCSI (работающий поверх Ethernet) продолжает отъедать долю у других блочных протоколов и встречается в 1/3 всех ЦОД которые я видел.
Мне сложно сравнивать SAS протокол с FC/FCoE/iSCSI, так как я не много знаю о его преимуществах. Следя за тенденциями и новыми развивающимися технологиями ЦОД, нигде для себя не замечал каких-то специальных, особых возможностей SAS, для того чтобы он занял место одного из выше перечисленных протоколов. Похоже он занял свою нишу и останется там.
Среди протоколов которые набирают популярность в ЦОД для подключения разнообразных хранилищ стоит отметить Ethernet.
Собственно об этом и статья, как сделать так, чтобы и бюджетно, и в будущем «лишнего» не покупать, и при этом всём иметь возможность вырасти, максимально утилизируя имеющееся оборудование.
Мне сложно сравнивать SAS протокол с FC/FCoE/iSCSI, так как я не много знаю о его преимуществах. Следя за тенденциями и новыми развивающимися технологиями ЦОД, нигде для себя не замечал каких-то специальных, особых возможностей SAS, для того чтобы он занял место одного из выше перечисленных протоколов. Похоже он занял свою нишу и останется там.
Среди протоколов которые набирают популярность в ЦОД для подключения разнообразных хранилищ стоит отметить Ethernet.
Собственно об этом и статья, как сделать так, чтобы и бюджетно, и в будущем «лишнего» не покупать, и при этом всём иметь возможность вырасти, максимально утилизируя имеющееся оборудование.
JBOD не проблема. Как и свичи (см. коммент ниже).
Я говорю, что почему-то широко это не исспользеутся, везде где я бывал. А бывал я во многих ЦОДах.
Может по-этому?
Может по-этому?
Что-же касается одного-двух серверов, то на мой взгляд лучше выбрать, сразу такую технологию, которая позволит масштабироваться вашему ЦОДу в будущем. И если SAS по-вашему мнению обеспечит такую возможность, почему бы и нет.
Но как я сказал ранее, смотрю со скептицизмом на SAS свичи потому, что их нигде в продакшине не видел.
Но как я сказал ранее, смотрю со скептицизмом на SAS свичи потому, что их нигде в продакшине не видел.
По поводу SAS-свичей пригодится материал на Хабре. Там же есть полезный коммент, поясняющий "популярность Ethernet в ЦОД для подключения разнообразных хранилищ". Вот он: iSCSI для проброса в другой город, SAS из области DAS.
Относительно приведенной ссылки, должен отметить, то латентность, как правило ухудшается не из-за сети, а из-за недостатка дисков. Собственно автор сам отметил что все было хорошо пока виртуальная инфраструктура не выросла. Так что сравнение FC и SAS в приведенном примере не корректно. Естественно на FC/FCoE/iSCSI латентность можно получить на много ниже, к примеру 1 мс на SSD дисках. Это простой пример показывающий что дело в основном в дисках, а не сети.
Кстати очень важно отметить важный феномен.
Следом за ростом компании неизбежно следует рост ЦОД. И админы такого ЦОДа должны немного опережать его развитие. А получается что они немного запаздывают:
Вместо того, чтобы админы думали об масштабируемости, отказоустойчивости, управляемости, репликации, удобстве резервного копирования и восстановления, они, «во главу» всего ставят «цену вопроса». И лишь спустя время, жизнь учит, расставит приоритеты и утрясёт всё так, что «цена вопроса» для них смещается с первого места. Иногда смещение происходит вместе с админом с рабочего места. И тогда они понимают, что «не в производительности счастье».
Симметрично этому феномену существует ещё один, который наблюдается в руководстве компании, заключается он в том, что финансы выделять не хоят они, а ответственность за работоспособность ЦОДа спрашивают почему-то с админов. По именно руководство бизнеса провоцирует первый феномен. и только после «Шеф всё пропало», финансы на «правильные» решения чудесным образом находятся.
Мой совет заключается в том, чтобы не допустить ситуации «финансы НЕ выделили мы, а ответственные за неработоспособность вы».
Следом за ростом компании неизбежно следует рост ЦОД. И админы такого ЦОДа должны немного опережать его развитие. А получается что они немного запаздывают:
Вместо того, чтобы админы думали об масштабируемости, отказоустойчивости, управляемости, репликации, удобстве резервного копирования и восстановления, они, «во главу» всего ставят «цену вопроса». И лишь спустя время, жизнь учит, расставит приоритеты и утрясёт всё так, что «цена вопроса» для них смещается с первого места. Иногда смещение происходит вместе с админом с рабочего места. И тогда они понимают, что «не в производительности счастье».
Симметрично этому феномену существует ещё один, который наблюдается в руководстве компании, заключается он в том, что финансы выделять не хоят они, а ответственность за работоспособность ЦОДа спрашивают почему-то с админов. По именно руководство бизнеса провоцирует первый феномен. и только после «Шеф всё пропало», финансы на «правильные» решения чудесным образом находятся.
Мой совет заключается в том, чтобы не допустить ситуации «финансы НЕ выделили мы, а ответственные за неработоспособность вы».
Картинка с сравнением Roadmaps Ethernet и FC очень «маркетинговая» в начале статьи. Официальные лица от FC пишут о другом тут: fibrechannel.org/fibre-channel-roadmaps.html
Например: 2016 год — это скорость интерфейсов 128G, а к 2019 году — 256Gb. Причем техническая спецификация на 128Gb была готова уже в 2014 году.
Например: 2016 год — это скорость интерфейсов 128G, а к 2019 году — 256Gb. Причем техническая спецификация на 128Gb была готова уже в 2014 году.
Sign up to leave a comment.
iSCSI 2.0 с FAS2xxx или путь масштабирования маленького ЦОДа