Лучшие практики совместного выполнения в Linux для файлов Azure NetApp — слоты сеансов и записи в таблице слотов.

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

NFSv3

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

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

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

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

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

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

• Учитывая задержку в 0,5 мс, для достижения 110 000 IOPS необходим параллелизм 55.
• Учитывая задержку в 1 мс, для достижения 155 000 операций ввода-вывода (I/OPS) требуется параллелизм в 155.

Подробнее см. в статье Производительность базы данных 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)
  • Подключение 1
    • Клиент делает не более 100 запросов к серверу по этому подключению.
    • Ожидается, что сервер будет принимать не более 128 запросов в обработке от клиента для этого подключения.
  • Подключение 2
    • Клиент делает не более 100 запросов к серверу по этому подключению.
    • Ожидается, что сервер будет принимать не более 128 запросов в обработке от клиента для этого подключения.
  • …
  • …
  • Подключение 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)
    • Клиент будет выдавать не более восьми запросов в полете на сервер для каждого подключения.
    • Сервер будет принимать не более 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)
    • Клиент будет выдавать не более восьми запросов в полете на сервер для каждого подключения.
    • Сервер будет принимать не более 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)
    • Клиент будет выдавать не более восьми запросов в полете на сервер для каждого подключения.
    • Сервер будет принимать не более 128 запросов от одного этого подключения.

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

Как вычислить оптимальное sunrpc.tcp_max_slot_table_entries

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

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

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

Объем ввода-вывода	Задержка	Ввод-вывод или пропускная способность	Конкуррентность
8 КиБ	0,5 мс	110 000 I/OPS | 859 MiB/s	55
8 КиБ	2 мс	400 000 I/OPS | 3,125 МиБ/с	восемьсот
256 КиБ	2 мс	16 000 I/OPS | 4000 MiB/s	32
256 КиБ	4 мс	32 000 I/OPS | 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, и требуется значение два или больше.

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

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

Пример 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)
  • Подключение 1
    • Клиент будет выдавать не более 32 одновременных запросов на сервер через это соединение.
    • Ожидается, что сервер будет принимать не более 32 одновременных запросов от клиента для этого подключения.
  • Подключение 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)
  • Подключение 1
    • Ожидается, что клиент будет хранить не более 90 промежуточных запросов к серверу из этого подключения.
    • Ожидается, что сервер будет обрабатывать не более 90 запросов от клиента для этого подключения во время сеанса.
  • Подключение 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 нас интересуют следующие пакеты.

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

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

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

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

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

• Рекомендации по прямому вводу-выводу Linux для Azure NetApp Files
• Рекомендации по кэшированию в файловых системах Linux для Azure NetApp Files
• Рекомендации по параметрам подключения NFS для Linux для Azure NetApp Files
• Лучшие практики для Linux NFS по упреждающему чтению
• Рекомендации по поддержанию номера SKU для виртуальных машин Azure
• Тесты производительности для Linux