По долгу службы, мне часто приходится анализировать NFS-трафик. Wireshark является моим основным инструментом и для него я даже создавал расширение на lua. Но чего-то не хватало. И вот две недели назад я наткнулся на новый для меня инструмент Packetbeat. К сожалению, paketbeat не поддерживает не поддерживал NFS, но этот недостаток мне удалось исправить.

Packetbeat

Paketbeat — это один из инструментов из комплекта beats от создателей elasticsearch, logstash и kibana. Это отправитель (shipper) данных в elasticsearch, который слушает сетевой трафик, конвертирует его в json-записи и посылает в elasticsearch. Если вы используете Kibana4, то есть стандартные панели для визуализации собранного трафика. На данный момент, packetbeat распознаёт TCP, UDP, DNS, ICMP, HTTP, memcache, MongoDB, redis, PostgreSQL, MySQL, thrift и, теперь уже, NFS. Где-то внутри, packetbeat использует libpcap.

На днях встал перед задачей, как определить, сколько времени тратит NFS сервер на запрос.
Оказалось, что это не так уж и просто посмотреть. Но на помощь пришёл любимый молоток инструмент — wireshark. Для wireshak можно написать своё расширение на LUA.

В статьe о dCache рассказано о том, как использовать его в качестве NFS сервера. Но функциональной совместимости с существующими клиентами недостаточно, чтобы системой можно было пользоваться. Производительность тоже должна быть на высоте. Рабочей лошадкой NFS протокола является ONCRPC протокол. В dCache мы используем собственную реализацию, основанную на grizzly nio framework.

Немного истории для молодых

ONC RPC (Open Network Computing Remote Procedure Call) — протокол, созданный Sun Microsystems в конце 80х и опубликован в 1995г вместе с NFSv2. ONCRPC получил быстрое распространение и широко использовался, пока в начале 2000 не был вытеснен модными альтернативами, как CORBA, SOAP, а позже REST и JSON-RPC. Тем не менее, ONCRPC всё ещё используется, где простота и скорость важнее моды — в сетевых файловых системах.

Реализация

Чтобы не изобретать очередной велосипед, вначале мы использовали реализацию Remote Tea, но вскоре столкнулись с ограничениями, которые не могли легко решить: IPv6, GSSAPI, NIO. Так что велосипед пришлось изобретать, но не с нуля. Мы максимально сохранили совместимость с RemoteTea и адаптировали уже написанный код.

В продолжение статьи о dCache расскажу о некоторых деталях внутренней реализации.

Одна из важных задач распределённых систем — как распределить нагрузку по имеющимся узлам. Для распределённого хранилища эта задача особо важна, так как решение принятое на стадии записи влияет на то, как данные будут прочитаны.

В последнее время было большое количество постов о ЦЕРНе и Большом Адронном Kоллайдере (БАК или LHC). Но не многие знают, что БАК производит ~20 ПБ данных в год. Порядка 50% всех данных хранится в dCache.

dCache является распределённой системой хранения данных, способной работать на обычном железе, с возможностью расширения посредсвом добавления новых узлов. Всё, что нужно для работы на узле, — это JVM (так как всё написано на джаве) и файловая система, где, собственно, и хранятся данные. Типичные инсталляции используют Linux(RHEL/SL/CentOS 6) или Solaris с XFS или ZFS, соответсвенно. В связи с натурой экспериментальных данных dCache не предусматривает изменение хранимых файлов.

dCache разрабатывается с 2000 года и с 2002 года используеться в более чем 80 научных центрах мира, включая Россию. Самые маленькие системы состоят из одного узла в несколько ТБ, самые большие состоят из ~500 узлов с суммарным дисковым пространством в 22 ПБ.