Pull to refresh

Comments 24

А как на счет скорости отклика в такой реализации?
Скорость отклика от приложения до хранилища через езернет сеть как правило практически такая же как и в Fibre Channel, иногда такая-же, в случае использования соответствующих датацентровых свитчей. Разница как правило на столько не велика, что ею можно пренебречь. Но это касается нетапа и свичей DCB, о других решениях не могу ничего сказать.
Почти — это на сколько? Вы проводили тесты? Есть результаты?
Так же можно попросить вас написать примерные модели для сравнения, где разница будет минимальна?
И еще интересует вопрос разницы по цене.
Вопросы задаю, так как присматриваюсь к данной технологии.
Да, нетап проводил тест для нагрузок баз данных и виртуализации, т.е. мелких блоков с случайной записью и порядка 70/30 R/W. Не уверен что могу их здесь выложить, так как такие документы нужно адекватно интерпретировать.
Но для нетапа к примеру nfs на 10 гб должен давать одинаковые показатели латенси и iops по сравнению с fc8. Если это не так, то точно есть проблема с сетью.
Могу сказать относительно латенси, что можно получить 0.5 мс (для этого нужен будет флеш) отклик для чтения и записи на езернет.
Относительно цены прошу обратиться к вашему локальному дистрибьютору или партнеру. Я технарь и работаю с технологиями а не ценами.
Сравнение с FC не проводил т.к. сразу решили остановиться на 10GbE. Конфиг: 8 хостов, 2 свича, FAS2240-2 четырьмя шнурками в свичи. Пока нагрузка не начинает упираться в диски, задержки по чтению/записи 1-1.5мс на 600Gb SAS дисках. Флэшпула и Флэшкэша нет. Старый флэшевый сторадж выдавал 1.5-2мс задержки, но там стоимость гига была значительно выше, а надёжности никакой (1 голова, 1 сетевуха). Так что, считаю, что на обычных винтах разницу с FC уловить будет крайне сложно. Всё упирается в винты. Если же покупать взрослый флэшевый сторадж, то тут уже и FC не спасёт, нужен Infiniband.
Смысл всё это городить, когда потом контроллер застенчиво (с дебаг-приоритетом) пишет в логах что-то типа «запись идёт слишком долго, операция заняла больше 60с: 360» и делает чистой воды таймаут на подмонтированных томах (на самих томах нет — а вот в ожидающем ответа софте — вполне). При этом соседний контроллер считает, что всё зашибись и никакого тейковера не происходит.

В ответ на претензию саппорт нетаппа говорит: «ой, но у вас не было perfdata на момент аварии, когда авария случится снова, соберите нам perfdata на этот момент, а пока мы вам ничем помочь не можем».

Типа, запись, выполняющаяся всего 300 секунд — это всё правильно и хорошо.

фигня эти ваши 300 секунд :)
Sun Nov 2 05:18:23 MSK [fas3210:NwkThd_00:warning]: NFS response to client… for volume 0x744d82e6 was slow, op was v3 remove, 100 > 60 (in seconds)
Sun Nov 2 23:01:33 MSK [fas3210:NwkThd_00:warning]: NFS response to client… for volume 0x744d82e6 was slow, op was v3 null, 4294967 > 60 (in seconds)
Ого. Сумели что-то от саппорта добиться?
Если очень захотеть то таймаут можно получить на любом протоколе. Здесь статья об оптимизации, а не траблшутинге вашей конкретной ситуации.
Вы эту историю торгуете на моей памяти уже два раза и это третий.
Статья никаким боком не касается вашего вопроса, кроме картинки NetApp FAS.

На сим прошу оффтоп закончить.
Я её не «торгую», я её рассказываю, чтобы не дай бог кто-то не подумал, что netapp надежное решение. Очевидный баг, который компания признавать отказывается, типа так и должно быть.

Расскажите мне, как операция io может занять сотни секунд по причине берста нагрузки от клиента? Лично мне очевидно, что это заскоки в логике самого контроллера, то есть вся хвалёная wafl'ность просто не может и не должна использоваться для критичных по аптайму задач.

И коммент выше от madorc только подтверждает, что это распространенная (и, судя по всему, не пофикшенная проблема).

Лично моё возмущение сводится даже не к факту, что оно жидко какается, а что саппорт предлагает дождаться очередной аварии и собирать в это время perfdata, а потом пытаться продавать диски по дороже (ну что вы хотели от дисков по $1000 за штуку?).
Вот именно об этом я и говорю хватит ее копи-пасть везде, где есть картинка нетапа. Прочтите название топика и вступление.

С тем подходом как вы начали этот тред, вы вряд-ли добьетесь моей преклонности и моего желания разбираться в вашей проблеме.

Еще раз: здесь топик не про траблшутинг, а я не техподдержка и даже не сотрудник нетапа, а тема про тюнинг езернет.
Здравствуйте.
У Вас на мой взгляд небольшая неточность:
То что произошло дальше — появилась «дуплексность», т.е. каждый узел мог одновременно и принимать и передавать фреймы по разным линкам: две пары RX и TX для узла и две для коммутатора.

Дуплексность появилась в 10BASE-T, IEEE 802.3i — для передачи данных используется 4 провода кабеля витой пары (две скрученные пары) категории-3 или категории-5. В категории 5 две пары запасные. Очень часто выручают) при разрыве передающей или принимающей пары.
Статья познавательная. Спасибо.
Есть еще одна неточность:
Потом Ethernet шагнул дальше начал использовать витую пару дав задел на будущее, но глупые бриджи точно также объединяли все узлы сети в один домен коллизии и ситуация по сути не изменилась.

Бридж bridgeмост, устройство второго уровня модели OSI, которое осуществляет передачу, основываясь на MAC адресах.

Простым копированием пакетов с одного порта на все прочие занимались сетевые концентраторы — хабы.
Спасибо, вы правы, подразумевал хаб.
Еще неточность про размеры mtu. Даже на 1 гбит. многие устройства до 9700 умеют, а у вас на 10Gb 9000 потолок.
А некоторое оборудование и 16К фреймы поддерживает
Здесь я специально говорил не совсем уж про все на свете коммутаторы. Но для тех, которые я привел в пример, проверял на сайте производителя. Идея была донести, что МТУ может быть разный, для разных устройств и его стоит подбирать в зависимости от того какой свич и узлы у вас есть чтобы значение совпадало на всем пути следования фрейма. И думаю мне эту мысль удалось донести.
Да конечно же 1ГБ может быть с jumbo frames. Но основная идея в том, что не иметь jumbo frames на 10гб это просто преступление.
Only those users with full accounts are able to leave comments. Log in, please.