Поделиться через

Рекомендации по параллелизму Linux для Azure NetApp Files — слоты сеансов и записей в таблице слотов

  • Статья

Сведения в этой статье помогут вам понять рекомендации по параллелизму касательно слотов сеансов и записей в таблице слотов для протокола NFS Azure NetApp Files.

NFSv3

В NFSv3 отсутствует механизм для согласования параллелизма между клиентом и сервером. Клиент и сервер сами определяют свои ограничения, не согласовывая это друг с другом. Для оптимальной производительности следует уровнять максимальное число записей в таблице слотов sunrpc на стороне клиента в соответствии с тем, что поддерживается на сервере без ответной реакции. Когда клиент переполняет сетевой стек сервера для обработки рабочей нагрузки, сервер реагирует на это уменьшением размера окна для подключения, что негативно сказывается на производительности.

По умолчанию современные ядра Linux определяют размер записи в таблице слотов sunrpc.tcp_max_slot_table_entries для каждого подключения sunrpc, поскольку поддерживается не более 65 536 невыполненных операций, как показано в следующей таблице.

Сервер Azure NetApp Files NFSv3
Максимальное число контекстов выполнения на подключение		 Клиент Linux
Максимальное число записей в таблице слотов sunrpc по умолчанию для каждого подключения
128 65 536

Эти записи в таблице слотов определяют ограничения параллелизма. Такие высокие значения не нужны. Например, при использовании теории очередей, известной как закон малых чисел, вы обнаружите, что скорость ввода-вывода определяется параллелизмом (т. е. необработанными операциями ввода-вывода) и задержкой. Таким образом, алгоритм доказывает, что 65 536 слотов — это на порядок выше того, что требуется для обеспечения даже очень ресурсоемких рабочих нагрузок.

Littles Law: (concurrency = operation rate × latency in seconds)

Уровень параллелизма не ниже 155 достаточно для достижения 155 000 операций Oracle DB NFS в секунду с помощью Oracle Direct NFS, которая является технологией, аналогичной nconnect концепцией подключения:

  • При задержке в 0,5 мс параллелизм со значением 55 обеспечивает 110 000 операций ввода-вывода в секунду.
  • При задержке в 1 мс параллелизм со значением 155 обеспечивает 155 000 операций ввода-вывода в секунду.

Oracle DNFS latency curve

Подробнее см. в статье Производительность базы данных Oracle в отдельных томах Azure NetApp Files.

Настраиваемое значение sunrpc.tcp_max_slot_table_entries — это параметр настройки на уровне соединения. Рекомендуется присвоить этому параметру значение 128 или меньше для каждого подключения, а количество слотов в рамках всей среды не должно превышать 10000.

Примеры количества слотов на основе рекомендаций по параллелизму

В примерах в этом разделе показано количество слотов на основе рекомендаций по параллелизму.

Пример 1. Один клиент NFS, 65 536 sunrpc.tcp_max_slot_table_entries и без nconnect для максимального параллелизма 128 на основе ограничения на стороне сервера в 128

Пример 1 основан на рабочей нагрузке одного клиента со значением sunrpc.tcp_max_slot_table_entry, по умолчанию равным 65 536, и одним сетевым подключением, т. е. без nconnect. В этом случае достижим параллелизм 128.

  • NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
    • Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)
      • В теории клиент может выдавать не более 65 536 промежуточных запросов на сервер для каждого подключения.
      • Сервер будет принимать не более 128 промежуточных запросов от этого единственного подключения.

Пример 2. Один клиент NFS, 128 sunrpc.tcp_max_slot_table_entries и без nconnect для максимального параллелизма 128

Пример 2 основан на рабочей нагрузке одного клиента со значением sunrpc.tcp_max_slot_table_entry, равным 128, и без параметра подключения nconnect. С этим параметром параллелизм 128 достижим для одного сетевого подключения.

  • NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
    • Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)
      • Клиент будет выдавать не более 128 промежуточных запросов на сервер для каждого подключения.
      • Сервер будет принимать не более 128 промежуточных запросов от этого единственного подключения.

Пример 3. Один клиент NFS, 100 sunrpc.tcp_max_slot_table_entries и nconnect=8 для максимального параллелизма 800

Пример 3 основан на одной клиентской рабочей нагрузке, но с меньшим sunrpc.tcp_max_slot_table_entry значением 100. На этот раз параметр подключения nconnect=8 используется для распределения рабочей нагрузки по 8 подключениям. С этим параметром достижим параллелизм 800 для всех 8 подключений. Это значение представляет собой параллелизм, необходимый для достижения показателя в 400 000 операций ввода-вывода в секунду.

  • NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
    • Connection 1 (10.10.10.10:2049, 10.10.10.11:6543,TCP), Connection 2 (10.10.10.10:2049, 10.10.10.11:6454,TCP)… Connection 8 (10.10.10.10:2049, 10.10.10.11:7321,TCP)
    • Подключение ion 1
      • Клиент будет выдавать не более 100 промежуточных запросов на сервер из этого подключения.
      • Ожидается, что сервер будет принимать не более 128 промежуточных запросов от клиента для этого подключения.
    • Подключение ion 2
      • Клиент будет выдавать не более 100 промежуточных запросов на сервер из этого подключения.
      • Ожидается, что сервер будет принимать не более 128 промежуточных запросов от клиента для этого подключения.
    • …
    • …
    • Подключение ion 8
      • Клиент будет выдавать не более 100 промежуточных запросов на сервер из этого подключения.
      • Ожидается, что сервер будет принимать не более 128 промежуточных запросов от клиента для этого подключения.

Пример 4. 250 клиентов NFS, 8 sunrpc.tcp_max_slot_table_entries и без nconnect для максимального параллелизма 2000

В примере 4 используется уменьшенное значение sunrpc.tcp_max_slot_table_entry для каждого клиента, равное 8, для среды EDA с 250 компьютерами. В этом сценарии параллелизм 2000 достигается на уровне среды, значения более чем достаточно для обеспечения серверной рабочей нагрузки EDA в 4000 МиБ/с.

  • NFS_Server=10.10.10.10, NFS_Client1=10.10.10.11
    • Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)
      • Клиент будет выдавать не более 8 промежуточных запросов на сервер для каждого подключения.
      • Сервер будет принимать не более 128 промежуточных запросов от этого единственного подключения.
  • NFS_Server=10.10.10.10, NFS_Client2=10.10.10.12
    • Connection (10.10.10.10:2049, 10.10.10.12:7820,TCP)
      • Клиент будет выдавать не более 8 промежуточных запросов на сервер для каждого подключения.
      • Сервер будет принимать не более 128 промежуточных запросов от этого единственного подключения.
  • …
  • …
  • NFS_Server=10.10.10.10, NFS_Client250=10.10.11.13
    • Connection (10.10.10.10:2049, 10.10.11.13:4320,TCP)
      • Клиент будет выдавать не более 8 промежуточных запросов на сервер для каждого подключения.
      • Сервер будет принимать не более 128 промежуточных запросов от этого единственного подключения.

При использовании NFSv3 общее количество слотов конечных точек хранилища не должно превышать 10000. Для каждого подключения значение sunrpc.tcp_max_slot_table_entries не должно превышать 128, когда приложение горизонтально увеличивает масштаб по нескольким сетевым подключениям (nconnect и HPC в целом, EDA в частности).

Как вычислить наиболее подходящее sunrpc.tcp_max_slot_table_entries

Используя закон малых чисел, можно вычислить общее количество необходимых записей в таблице слотов. В целом следует учитывать следующие факторы.

  • Горизонтальное увеличение масштаба рабочих нагрузок зачастую является крупным и последовательным по своей природе.
  • Рабочие нагрузки базы данных, в особенности OLTP, часто являются случайными.

В следующей таблице показан пример исследования параллелизма с произвольными задержками.

Объем ввода-вывода Задержка Ввод-вывод или пропускная способность Параллелизм
8 КиБ 0,5 мс 110 000 операций ввода-вывода в секунду | 859 MiB/s 55
8 КиБ 2 мс 400 000 операций ввода-вывода в секунду | 3,125 МиБ/с 800
256 КиБ 2 мс 16 000 операций ввода-вывода в секунду | 4000 MiB/s 32
256 КиБ 4 мс 32 000 операций ввода-вывода в секунду | 8000 МиБ/с 128

Вычисление параметров параллелизма по количеству подключений

Например, рабочая нагрузка представляет собой ферму EDA, а все 1250 клиентов в ней выполняют рабочую нагрузку в одной той же конечной точке хранилища (конечная точка хранилища — это IP-адрес хранилища); затем вы вычисляете необходимую скорость ввода-вывода и разделяете параллелизм в ферме.

Предположим, что рабочая нагрузка составляет 4000 МиБ/с при использовании среднего размера операции в 256 КиБ и средней задержки в 10 мс. Для вычисления параллелизма используйте следующую формулу.

(concurrency = operation rate × latency in seconds)

В результате вычисления мы получаем параллелизм 160.

(160 = 16,000 × 0.010)

Учитывая потребность в 1250 клиентах, можно безопасно задать для параметра sunrpc.tcp_max_slot_table_entries значение 2 для каждого клиента, чтобы достичь показателя в 4000 МиБ/с. Однако можно сформировать дополнительный запас, задав для каждого клиента значение 4 или даже 8, учитывая рекомендуемое ограничение в 10000 слотов.

Настройка sunrpc.tcp_max_slot_table_entries на клиенте

  1. Добавьте sunrpc.tcp_max_slot_table_entries=<n> в файл конфигурации /etc/sysctl.conf.
    Если при настройке оптимальным окажется значение меньше 128, замените 128 на соответствующее число.
  2. Выполните следующую команду:
    $ sysctl -p
  3. Подключите (или повторное подключите) все файловые системы NFS, поскольку настройка применяется только к подключениям, созданным после установки настройки.

NFS версии 4.1

В NFS версии 4.1 сеансы определяют связь между клиентом и сервером. Применяются ли подключенные файловые системы NFS на вершине одного подключения или много (как и в случае с nconnect), применяются правила для сеанса. Во время установки сеанса клиент и сервер согласовывают максимальное количество запросов для сеанса, задавая меньшее из двух поддерживаемых значений. Azure NetApp Files поддерживает 180 необработанных запросов, а клиенты Linux по умолчанию поддерживают 64. Ограничения сеанса представлены в таблице ниже.

Сервер Azure NetApp Files NFSv4.1
Максимальное количество команд на сеанс		 Клиент Linux
Максимальное число команд по умолчанию на сеанс		 Согласованное максимальное число команд для сеанса
180 64 64

Несмотря на то что клиенты Linux по умолчанию поддерживают не более 64 запросов на сеанс, значение параметра max_session_slots можно настраивать. Чтобы изменения вступили в силу, требуется перезагрузка. Используйте команду systool -v -m nfs, чтобы просмотреть текущее максимальное значение, используемое клиентом. Чтобы команда работала, требуется хотя бы одно подключение NFS версии 4.1.

$ systool -v -m nfs
{
Module = "nfs"
...
  Parameters:
...
    max_session_slots   = "64"
...
}

Для настройки max_session_slots создайте файл конфигурации в разделе /etc/modprobe.d. Убедитесь, что для строки в файле нет кавычек. В противном случае параметр не вступит в силу.

$ sudo echo “options nfs max_session_slots=180” > /etc/modprobe.d/nfsclient.conf $ sudo reboot

Azure NetApp Files ограничивает число команд в каждом сеансе до 180. В таком случае рекомендуется максимальное значение 180, которое в настоящее время можно настроить. Клиент не сможет достичь параллелизма выше 128, если только сеанс не разделен на несколько подключений, поскольку Azure NetApp Files ограничивает каждое подключение до максимум 128 команд NFS. Чтобы получить несколько подключений, рекомендуется использовать параметр подключения nconnect, а также значение 2 или больше.

Примеры ожидаемых максимальных значений параллелизма

В примерах в этом разделе показан ожидаемый максимум параллелизма.

Пример 1 — 64 max_session_slots и без nconnect

Пример 1 основан на значении по умолчанию 64 max_session_slots и без параметра nconnect. Такая настройка позволяет добиться параллелизма 64 — все для одного сетевого подключения.

  • NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
    • Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)
      • Клиент будет выдавать не более 64 промежуточных запросов на сервер для сеанса.
      • Сервер будет принимать не более 64 промежуточных запросов от клиента для сеанса. (64 — это согласованное значение.)

Пример 2 — 64 max_session_slots и nconnect=2

Пример 2 основан на максимум 64 session_slots и с добавлением параметра подключения nconnect=2. Параллелизм 64 достижим, но он делится на два подключения. Несмотря на то что в этом сценарии для нескольких подключений не удается добиться большего параллелизма, уменьшенная глубина очереди для подключения положительное влияет на задержку.

Если использовать max_session_slots со значением 64 и параметр nconnect=2, вы увидите, что максимальное количество запросов делится между подключениями.

  • NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
    • Connection 1 (10.10.10.10:2049, 10.10.10.11:6543,TCP) && Connection 2 (10.10.10.10:2049, 10.10.10.11:6454,TCP)
    • Подключение ion 1
      • Клиент будет выдавать не более 32 промежуточных запросов на сервер из этого подключения.
      • Ожидается, что сервер будет принимать не более 32 промежуточных запросов от клиента для этого подключения.
    • Подключение ion 2
      • Клиент будет выдавать не более 32 промежуточных запросов на сервер из этого подключения.
      • Ожидается, что сервер будет принимать не более 32 промежуточных запросов от клиента для этого подключения.

Пример 3 — 180 max_session_slots и без nconnect

В примере 3 не используется параметр подключения nconnect, а параметру max_session_slots задается значение 180, соответствующее максимальному параллелизму сеансов NFS версии 4.1 на сервере. В этом сценарии при наличии только одного подключения и при наличии максимум 128 необработанных операций Azure NetApp Files на подключение NFS сеанс ограничен 128 промежуточными операциями.

Несмотря на то что для параметра max_session_slots задано значение 180, одно сетевое подключение ограничивается максимум 128 запросами.

  • NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
    • Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)
      • Клиент будет выдавать не более 180 промежуточных запросов на сервер для сеанса.
      • Сервер будет принимать не более 180 промежуточных запросов от клиента для сеанса.
      • Сервер будет принимать не более 128 промежуточных запросов от единственного подключения.

Пример 4 — 180 max_session_slots и nconnect=2

В примере 4 добавляется параметр подключения nconnect=2 и используется значение 180 для max_session_slots. Поскольку общая рабочая нагрузка делится между двумя подключениями, достигается 180 необработанных операций.

При наличии двух подключений сеанс поддерживает все 180 необработанных запросов.

  • NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
    • Connection 1 (10.10.10.10:2049, 10.10.10.11:6543,TCP) && Connection 2 (10.10.10.10:2049, 10.10.10.11:6454,TCP)
    • Подключение ion 1
      • Ожидается, что клиент будет хранить не более 90 промежуточных запросов к серверу из этого подключения.
      • Ожидается, что сервер будет хранить не более 90 промежуточных запросов от клиента для этого подключения в рамках сеанса.
    • Подключение ion 2
      • Ожидается, что клиент будет хранить не более 90 промежуточных запросов к серверу из этого подключения.
      • Ожидается, что сервер будет хранить не более 90 промежуточных запросов от клиента для этого подключения в рамках сеанса.

Примечание.

Для обеспечения максимального уровня параллелизма задайте для параметра max_session_slots значение 180, что соответствует максимальному уровню параллелизма для сеанса, который в настоящее время поддерживается Azure NetApp Files.

Проверка максимального количества необработанных запросов для сеанса

Чтобы просмотреть размеры session_slot, поддерживаемые клиентом и сервером, найдите команду подключения в трассировке пакетов. Найдите вызов CREATE_SESSION и ответ CREATE_SESSION, как показано в следующем примере. Вызов от клиента и ответ, полученный от сервера.

Чтобы найти команду подключения, используйте следующую команду tcpdump.

$ tcpdump -i eth0 -s 900 -w /tmp/write.trc port 2049

В Wireshark нас интересуют следующие пакеты.

Screenshot that shows packets of interest.

В этих двух пакетах обратите внимание на поле max_reqs в среднем разделе файла трассировки.

  • Сетевая файловая система
    • Операций
      • Opcode
        • csa_fore_channel_attrs
        • max reqs

Пакет 12 (максимальное число запросов клиента) показывает, что значение max_session_slots для клиента было равным 64. В следующем разделе обратите внимание на то, что сервер поддерживает параллелизм 180 для сеанса. Сеанс завершается согласованием наименьшего из двух указанных значений.

Screenshot that shows max session slots for Packet 12.

В следующем примере показан пакет 14 (максимальное количество запросов сервера).

Screenshot that shows max session slots for Packet 14.

Следующие шаги