Комментарии 24
А как на счет скорости отклика в такой реализации?
Скорость отклика от приложения до хранилища через езернет сеть как правило практически такая же как и в Fibre Channel, иногда такая-же, в случае использования соответствующих датацентровых свитчей. Разница как правило на столько не велика, что ею можно пренебречь. Но это касается нетапа и свичей DCB, о других решениях не могу ничего сказать.
Почти — это на сколько? Вы проводили тесты? Есть результаты?
Так же можно попросить вас написать примерные модели для сравнения, где разница будет минимальна?
И еще интересует вопрос разницы по цене.
Вопросы задаю, так как присматриваюсь к данной технологии.
Так же можно попросить вас написать примерные модели для сравнения, где разница будет минимальна?
И еще интересует вопрос разницы по цене.
Вопросы задаю, так как присматриваюсь к данной технологии.
Да, нетап проводил тест для нагрузок баз данных и виртуализации, т.е. мелких блоков с случайной записью и порядка 70/30 R/W. Не уверен что могу их здесь выложить, так как такие документы нужно адекватно интерпретировать.
Но для нетапа к примеру nfs на 10 гб должен давать одинаковые показатели латенси и iops по сравнению с fc8. Если это не так, то точно есть проблема с сетью.
Могу сказать относительно латенси, что можно получить 0.5 мс (для этого нужен будет флеш) отклик для чтения и записи на езернет.
Но для нетапа к примеру 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 секунд — это всё правильно и хорошо.
В ответ на претензию саппорт нетаппа говорит: «ой, но у вас не было 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 FAS.
На сим прошу оффтоп закончить.
Я её не «торгую», я её рассказываю, чтобы не дай бог кто-то не подумал, что netapp надежное решение. Очевидный баг, который компания признавать отказывается, типа так и должно быть.
Расскажите мне, как операция io может занять сотни секунд по причине берста нагрузки от клиента? Лично мне очевидно, что это заскоки в логике самого контроллера, то есть вся хвалёная wafl'ность просто не может и не должна использоваться для критичных по аптайму задач.
И коммент выше от madorc только подтверждает, что это распространенная (и, судя по всему, не пофикшенная проблема).
Лично моё возмущение сводится даже не к факту, что оно жидко какается, а что саппорт предлагает дождаться очередной аварии и собирать в это время perfdata, а потом пытаться продавать диски по дороже (ну что вы хотели от дисков по $1000 за штуку?).
Расскажите мне, как операция io может занять сотни секунд по причине берста нагрузки от клиента? Лично мне очевидно, что это заскоки в логике самого контроллера, то есть вся хвалёная wafl'ность просто не может и не должна использоваться для критичных по аптайму задач.
И коммент выше от madorc только подтверждает, что это распространенная (и, судя по всему, не пофикшенная проблема).
Лично моё возмущение сводится даже не к факту, что оно жидко какается, а что саппорт предлагает дождаться очередной аварии и собирать в это время perfdata, а потом пытаться продавать диски по дороже (ну что вы хотели от дисков по $1000 за штуку?).
Вот именно об этом я и говорю хватит ее копи-пасть везде, где есть картинка нетапа. Прочтите название топика и вступление.
С тем подходом как вы начали этот тред, вы вряд-ли добьетесь моей преклонности и моего желания разбираться в вашей проблеме.
Еще раз: здесь топик не про траблшутинг, а я не техподдержка и даже не сотрудник нетапа, а тема про тюнинг езернет.
С тем подходом как вы начали этот тред, вы вряд-ли добьетесь моей преклонности и моего желания разбираться в вашей проблеме.
Еще раз: здесь топик не про траблшутинг, а я не техподдержка и даже не сотрудник нетапа, а тема про тюнинг езернет.
Вопрос был давно разрешен. Смотрите по ссылке.
Здравствуйте.
У Вас на мой взгляд небольшая неточность:
Дуплексность появилась в 10BASE-T, IEEE 802.3i — для передачи данных используется 4 провода кабеля витой пары (две скрученные пары) категории-3 или категории-5. В категории 5 две пары запасные. Очень часто выручают) при разрыве передающей или принимающей пары.
Статья познавательная. Спасибо.
У Вас на мой взгляд небольшая неточность:
То что произошло дальше — появилась «дуплексность», т.е. каждый узел мог одновременно и принимать и передавать фреймы по разным линкам: две пары RX и TX для узла и две для коммутатора.
Дуплексность появилась в 10BASE-T, IEEE 802.3i — для передачи данных используется 4 провода кабеля витой пары (две скрученные пары) категории-3 или категории-5. В категории 5 две пары запасные. Очень часто выручают) при разрыве передающей или принимающей пары.
Статья познавательная. Спасибо.
Есть еще одна неточность:
Бридж bridge — мост, устройство второго уровня модели OSI, которое осуществляет передачу, основываясь на MAC адресах.
Простым копированием пакетов с одного порта на все прочие занимались сетевые концентраторы — хабы.
Потом Ethernet шагнул дальше начал использовать витую пару дав задел на будущее, но глупые бриджи точно также объединяли все узлы сети в один домен коллизии и ситуация по сути не изменилась.
Бридж bridge — мост, устройство второго уровня модели OSI, которое осуществляет передачу, основываясь на MAC адресах.
Простым копированием пакетов с одного порта на все прочие занимались сетевые концентраторы — хабы.
Спасибо, добавил информацию.
Еще неточность про размеры mtu. Даже на 1 гбит. многие устройства до 9700 умеют, а у вас на 10Gb 9000 потолок.
А некоторое оборудование и 16К фреймы поддерживает
Здесь я специально говорил не совсем уж про все на свете коммутаторы. Но для тех, которые я привел в пример, проверял на сайте производителя. Идея была донести, что МТУ может быть разный, для разных устройств и его стоит подбирать в зависимости от того какой свич и узлы у вас есть чтобы значение совпадало на всем пути следования фрейма. И думаю мне эту мысль удалось донести.
Да конечно же 1ГБ может быть с jumbo frames. Но основная идея в том, что не иметь jumbo frames на 10гб это просто преступление.
--
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ненадёжный Ethernet