Как настроить кэш-сервер для компьютерного клуба на Supermicro?
Кэш-сервер для компьютерного клуба сохраняет поддерживаемые игровые загрузки и отдаёт повторно запрошенные блоки по локальной сети. Когда двадцать или пятьдесят ПК устанавливают одну и ту же версию игры, внешний канал не должен заново переносить каждому весь одинаковый объём. Для этой задачи на сервере Supermicro можно развернуть LanCache и выделить быстрый том SSD/NVMe.
Однако кэш не ускоряет любой интернет-трафик, не повышает FPS и не заменяет сервер бездисковой загрузки. Эффект зависит от повторяемости загрузок, поддерживаемых доменов и протоколов, DNS, дисков, сети и скорости установки на клиенте. Разберём расчёт, конфигурацию и проверку результата без обещаний «любая игра на всех ПК за минуту».
Что такое LanCache и как работает кэш-сервер?
LanCache — набор компонентов для локального кэширования загрузок. В типовой схеме DNS направляет запросы к поддерживаемым адресам доставки контента на ваш кэш. Если нужного блока ещё нет, сервер получает его из интернета, сохраняет и передаёт клиенту. При повторном запросе блок может быть отдан локально.
Таким образом, есть два принципиально разных режима: MISS — промах, когда данные приходится получать снаружи, и HIT — попадание, когда сохранённый блок доступен в кэше. Между ними бывают промежуточные состояния, например ожидание уже загружаемого блока. Нельзя оценивать весь проект по одной цифре скорости первой установки.
Новая версия игры, другой набор файлов или вытесненные данные снова потребуют загрузки из интернета. Слоган «скачать один раз» относится к повторно используемому содержимому, а не ко всему будущему трафику клуба. Игровой клиент по-прежнему проверяет лицензию, получает служебные ответы и устанавливает файлы на свой накопитель.
Кэш, файловый сервер, iSCSI и бездисковый клуб: в чём разница?
| Решение | Что получает ПК | Где выполняется игра | Главная задача |
|---|---|---|---|
| LanCache | Повторно используемые блоки загрузки | На игровом ПК после установки | Снизить повторный WAN-трафик |
| Файловая шара | Доступ к файлам по SMB/NFS | Зависит от приложения и способа установки | Общий файловый доступ |
| iSCSI / централизованное хранилище | Блочное устройство | На клиенте, использующем сетевые данные | Предоставить блочное хранение |
| Бездисковая загрузка | ОС и рабочую среду по сети | На клиентском ПК | Централизовать загрузку и обслуживание рабочих мест |
Для LanCache сервер не обязан хранить единственную рабочую копию пользовательских данных. Но его отказ способен нарушить разрешение имён или загрузку, если инфраструктура не предусматривает обход. Поэтому «данные кэша можно пересоздать» не означает «простой кэш-сервера ничем не повредит».
Если задача — общие папки и резервные копии, логичнее начать с сравнения NAS и сервера хранения. Здесь рассматривается именно ускорение повторных игровых загрузок.
Какие игры и обновления можно кэшировать?
Возможность определяется текущим способом доставки конкретного контента. Важны поддерживаемые домены, использование HTTP, правила игрового клиента и изменения инфраструктуры дистрибьютора. Один и тот же лаунчер способен получать часть данных через кэш, а часть — напрямую.
Обычный LanCache не расшифровывает HTTPS для сохранения содержимого. Передача такого соединения через прокси не делает его кэшируемым. Не нужно устанавливать на игровые ПК собственный корневой сертификат или отключать проверку TLS ради стандартной схемы LanCache.
Список поддерживаемых доменов обновляют вместе с программной конфигурацией и проверяют на фактических играх клуба. Нельзя обещать полный набор популярных платформ на годы вперёд. Перед закупкой выберите пять-десять наиболее важных игр, проверьте их чистую загрузку и повторную установку на другом ПК, измерьте объём WAN-трафика.
В современные варианты Compose обработка HTTPS может входить непосредственно в monolithic. Поэтому отдельный контейнер SNI proxy не является обязательной третьей службой в любой установке. Состав компонентов определяет конкретная проверенная версия, а не старое руководство.
Сколько интернет-трафика экономит кэш: пример на 50 ПК
Возьмём учебную ситуацию: 50 компьютеров устанавливают одинаковые 100 ГБ поддерживаемого содержимого, кэш изначально пуст, а последующие клиенты запрашивают те же сохранённые блоки. Объём без повторного использования — 50 × 100 = 5000 ГБ, то есть 5 ТБ в десятичной системе.
В идеализированной схеме один набор 100 ГБ приходит извне, остальные 4900 ГБ выдаются локально. Верхняя оценка сокращения внешнего трафика содержимого — 98%. Это не прогноз для любого клуба: обновления, различия языков и наборов файлов, HTTPS, вытеснение и служебные запросы снижают реальную долю попаданий.
| Доля попаданий по байтам | Повторно обслуживаемый объём при 5 ТБ запросов | Расчётный внешний объём |
|---|---|---|
| 0% | 0 ТБ | 5 ТБ |
| 60% | 3 ТБ | 2 ТБ |
| 80% | 4 ТБ | 1 ТБ |
| 98% | 4,9 ТБ | 0,1 ТБ |
Приближённо: WAN-объём содержимого = общий запрошенный объём × (1 − byte hit ratio). Запросы считают за один и тот же интервал; метаданные, авторизация и иной некэшируемый трафик учитываются отдельно. Доля HIT по числу запросов может выглядеть высокой из-за множества маленьких файлов и не отражать экономию в гигабайтах.
Если одинаковая игра уже установлена и почти не обновляется, ежедневный эффект может быть небольшим. Кэш особенно полезен при переустановках, регулярных обновлениях одинаковых игр и событиях с большим числом клиентов.
Какую сеть выбрать: 1, 10, 25 или 100 Гбит/с?
Разделяйте скорость одного ПК, суммарный порт сервера и пропускную способность коммутаторов. Двадцать клиентов по 1 Гбит/с могут вместе запросить до 20 Гбит/с, хотя ни один не получит больше своего гигабитного порта.
| Линия | Теоретический предел | Что ограничивает результат |
|---|---|---|
| 1 Гбит/с | 125 МБ/с | Протоколы, клиентский SSD, распаковка |
| 10 Гбит/с | 1250 МБ/с | Чтение массива и число одновременных клиентов |
| 25 Гбит/с | 3125 МБ/с | SSD, PCIe, CPU, коммутатор и его uplink |
| 100 Гбит/с | 12 500 МБ/с | Полный тракт сервера и суммарная способность клиентов |
Здесь МБ и ГБ — десятичные единицы, накладные расходы не учтены. В примере с 5 ТБ последовательная передача по внешнему каналу 1 Гбит/с имеет арифметический минимум около 11 часов 7 минут. Фактическая загрузка и установка займут больше времени.
После полного прогрева 4900 ГБ повторных данных через общий uplink 25 Гбит/с потребуют минимум около 26 минут 8 секунд только на передачу. Это нижняя граница для всего объёма, а не обещание завершения установки на каждом ПК. Диски, распаковка, собственные лимиты лаунчера и последовательность запросов способны стать более узким местом.
Два порта по 10 Гбит/с не означают 20 Гбит/с одному клиенту. Агрегация может распределять несколько соединений, но её эффект зависит от хэширования и клиентского поведения. Начинайте со схемы портов и uplink каждого коммутатора: единственный 1GbE-переход между этажами способен ограничить весь зал.
Как рассчитать объём SSD и ресурс записи?
Кэш хранит уникальное повторно используемое содержимое, а не отдельную полную копию для каждого игрового ПК. Поэтому формула «число ПК × весь размер библиотеки» для ёмкости кэша обычно неверна. Число одновременных клиентов влияет прежде всего на производительность.
Базовая модель: объём актуального набора + востребованные прежние блоки/версии + запас на обновления + свободное место и логи. Например, 30 игр по условным 80 ГБ дают 2,4 ТБ исходной оценки. С запасом 30% получается 3,12 ТБ до уточнения единиц и фактического состава загрузок. Размер установленной игры и объём кэшируемой загрузки могут различаться.
Для 10GbE нижняя граница чтения — 1,25 ГБ/с до накладных расходов; одиночный SATA SSD не следует считать достаточным для насыщения такого порта. У NVMe проверяют устойчивую скорость нескольких параллельных чтений, температуру и поведение при одновременном заполнении. Результат короткого теста на пустом накопителе не описывает работу заполненного тома.
Ресурс записи зависит от новых загружаемых данных, повторных промахов после вытеснения, журналов и устройства массива. Если поступает 0,5 ТБ нового кэша в сутки, это около 182,5 ТБ за условный год до дополнительных записей. В зеркале такой поток записывается на каждый участник; RAID0 распределяет его иначе, но отказ одного диска может уничтожить весь том.
Отказ от зеркала допустим только как осознанное решение для восстанавливаемого содержимого с понятным временем возврата сервиса. Конфигурацию DNS, Compose и секреты доступа к администрированию всё равно нужно защищать отдельно. Подробную настройку массива здесь не повторяем: она разобрана в инструкции по RAID Supermicro.
Сколько CPU и RAM нужно серверу клуба?
Число игровых мест само по себе не задаёт конфигурацию. Для двадцати ПК с двумя одновременными обновлениями и для двадцати одновременно переустанавливаемых машин профиль различается. Начальный стенд выбирают по целевой суммарной скорости и числу параллельных загрузок.
| Профиль проверки | Начальный аппаратный кандидат | Что подтвердить на стенде |
|---|---|---|
| До 4 активных клиентов с 1GbE | 4–8 современных CPU-ядер, 32 ГБ RAM, SSD/NVMe, порт 10GbE | Стабильность чтения и установка четырёх клиентов |
| Около 10 активных клиентов с 1GbE | 8–12 ядер, 64 ГБ RAM, несколько SSD/NVMe, 10/25GbE | Суммарная полоса, очереди дисков, записи MISS одновременно с HIT |
| Около 20 активных клиентов с 1GbE | 12–24 ядра, 128 ГБ RAM, NVMe-массив, 25GbE и выше по расчёту | CPU/IRQ, рабочий набор, uplink и клиентские ограничения |
Это профили для начала испытаний, а не гарантированные нормы LanCache и не результаты тестов перечисленных комплектаций. Если измерения показывают достаточность меньшего CPU, покупать дополнительные ядра ради числа мест не нужно. Если узкое место — SSD или сетевой переход, замена CPU также может не помочь.
RAM используют ОС, процессы, файловый кэш и индекс nginx. Для индекса ориентир проекта — порядка 250m на 1 ТБ настроенного дискового кэша; общий объём RAM должен быть больше. Увеличение CACHE_INDEX_SIZE не превращает всю эту память в кэш содержимого. Не нужно требовать, чтобы вся игровая библиотека помещалась в RAM.
В проекте Linus Tech Tips использовался Supermicro SYS-510P-WTR. Это пример из ролика, а не единственная подходящая модель. В каталоге серверов Supermicro аппаратную основу выбирают по накопителям, NIC, PCIe, обслуживанию и месту установки.
Как развернуть LanCache: пример Compose-конфигурации
Ниже — учебный вариант для выделенного Linux-сервера с Docker Engine и Compose plugin. Адрес 10.20.30.10 должен быть заранее назначен серверу в вашей локальной сети. Сетевой диапазон, upstream DNS, путь тома и лимиты заменяют на свои. Команды не предназначены для случайного выполнения на рабочем маршрутизаторе или контроллере домена.
Подготовьте постоянный том /srv/lancache, проверьте его монтирование и свободные байты. Для примера используется лимит кэша 3000g: он должен помещаться в том вместе с резервом и логами. Не считайте коммерческие «3,84 ТБ» равными 3840 двоичным гигабайтам.
# Файл .env
USE_GENERIC_CACHE=true
LANCACHE_IP=10.20.30.10
DNS_BIND_IP=10.20.30.10
UPSTREAM_DNS=192.0.2.53
CACHE_ROOT=/srv/lancache
CACHE_DISK_SIZE=3000g
MIN_FREE_DISK=100g
CACHE_INDEX_SIZE=1000m
TZ=Europe/Moscow
192.0.2.53 — пример адреса для документации, а не работающий DNS. Здесь обязательно укажите доступный разрешённый upstream-резолвер. Он не должен отправлять обслуживаемые запросы обратно на этот же lancache-dns, создавая цикл. При наличии домена AD или внутренних зон учитывайте их разрешение в согласованной DNS-схеме.
# Файл compose.yaml
services:
dns:
image: lancachenet/lancache-dns:latest
env_file: .env
restart: unless-stopped
ports:
- "${DNS_BIND_IP}:53:53/udp"
- "${DNS_BIND_IP}:53:53/tcp"
monolithic:
image: lancachenet/monolithic:latest
env_file: .env
restart: unless-stopped
ports:
- "${LANCACHE_IP}:80:80/tcp"
- "${LANCACHE_IP}:443:443/tcp"
volumes:
- "${CACHE_ROOT}/cache:/data/cache"
- "${CACHE_ROOT}/logs:/data/logs"
Пример показывает двухслужебную схему с обработкой HTTPS внутри monolithic. Политика перезапуска здесь задана явно. Тег latest удобен для первого стенда, но изменяем: после проверки сохраните конкретные digest образов, версию конфигурации и дату теста. Обновление сначала проверяют, а затем переносят в рабочую среду.
docker compose config
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=100 dns monolithic
Не публикуйте полный вывод docker compose config, если в вашем проекте есть секреты. В этом примере их нет. Перед стартом убедитесь, что выбранные адреса и порты свободны, включая TCP и UDP 53. Не отключайте системный DNS-сервис вслепую ради освобождения порта: сначала выясните, на каком адресе возникает конфликт.
Как настроить DNS, чтобы клиенты попадали в кэш?
LanCache должен находиться на пути разрешения имён поддерживаемого контента. В простом выделенном сегменте DHCP выдаёт клиентам адрес lancache-dns, а этот резолвер передаёт прочие запросы согласованному upstream. После изменения нужно обновить клиентскую конфигурацию и проверить фактический используемый резолвер.
Публичный DNS как «второй сервер на всякий случай» не гарантирует использование кэша: клиент может обратиться к нему и получить внешний CDN-адрес. Для резервирования нужны два согласованно работающих резолвера или другой спроектированный маршрут. Они не должны произвольно обходить правила кэширования.
В сети AD клиенты должны продолжать корректно разрешать доменные записи. Можно встроить правила для поддерживаемых CDN в действующую управляемую DNS-систему или организовать другую согласованную цепочку. Подмена доменного DNS без проверки способна сломать вход пользователей и внутренние службы.
Проверяйте и IPv6, VPN, защищённый DNS и встроенное поведение лаунчера. Рабочая IPv4-подмена не доказывает прохождение всех загрузок тем же путём. При наличии IPv6 не нужно отключать его во всей сети автоматически — сначала определите фактический маршрут запросов.
Как проверить, что LanCache действительно работает?
Выберите поддерживаемую игру, которой ещё нет в кэше, и два клиентских ПК. Не удаляйте весь рабочий кэш ради каждого теста. Зафиксируйте настройки Steam или другого лаунчера: встроенный обмен между клиентами способен повлиять на результат и должен быть исключён из сравнительного прогона либо учтён отдельно.
- Проверьте адрес DNS на клиенте и ответ по реально используемому поддерживаемому домену доставки. Для проверки можно использовать
nslookupилиdig. - Загрузите выбранное содержимое на первом ПК. Сопоставьте время, входящий WAN-трафик, запись на кэш-том и записи MISS.
- Повторите ту же загрузку на втором ПК после сохранения нужных блоков. Ищите HIT и снижение внешнего трафика при росте локальной отдачи.
- Сравните переданные байты за одинаковый интервал, ошибки и время полной установки, а не только пиковую цифру в лаунчере.
- Повторите с несколькими клиентами и одновременно поступающим новым содержимым.
Проверяйте сетевой тракт отдельно от дисков. Тест между сервером и ПК с iperf3 показывает возможности выбранного соединения, но не измеряет чтение кэша и установку игры. И наоборот, медленная распаковка клиента может скрывать исправную сеть и быстрый SSD.
Формат access log зависит от версии образа. Сначала найдите фактический журнал в выделенном каталоге logs и проверьте его поля. Не рассчитывайте byte hit ratio по случайно выбранной колонке и не считайте каждый HIT равным по размеру.
Почему кэш работает медленно или не даёт HIT?
| Симптом | Вероятные направления проверки | Первое действие |
|---|---|---|
| Второй ПК снова активно скачивает из интернета | DNS, другой набор блоков, HTTPS, домены, вытеснение | Сопоставить адреса подключения и журналы обеих загрузок |
| HIT есть, но скорость низкая | Порт клиента, uplink, SSD, CPU, распаковка | Разделить сетевой тест и измерение дискового чтения |
| Первое скачивание медленнее прямого | Проксирование, запись SSD, соединения, клиентское поведение | Повторить одинаковый холодный тест и сравнить узкие места |
| После перезагрузки ничего не работает | Монтирование тома, IP, политика перезапуска, порты | Проверить Compose, маршруты и наличие данных на нужном томе |
| Кэш постоянно вытесняет востребованные игры | Лимит ёмкости, рабочий набор, обновления и свободное место | Измерить byte hit ratio и новый объём за неделю |
Не начинайте настройку скорости с изменения размера slice. Более крупный блок может увеличить объём лишней загрузки при маленьком запросе и время ожидания другими клиентами. Изменение параметров способно сделать уже накопленные блоки непригодными для повторного использования. Сначала проверяют оборудование и маршрут, затем изменяют один параметр на стенде.
Нужен ли LanCache, если Steam умеет передавать игры по локальной сети?
Встроенная локальная передача Steam — отдельная альтернатива, которую разумно включить в пилот. В одном случае достаточно уже работающих клиентских ПК, в другом удобнее выделенный постоянно доступный источник. Решение зависит от поддерживаемых сценариев, настроек доступа, наличия нужной версии игры на источнике и нагрузки на него.
Выделенный кэш позволяет централизованно управлять своим объёмом и измерять повторное использование поддерживаемого контента разных источников. Но ради небольшого числа редких установок отдельный сервер может не окупиться. Если игры уже централизованно доставляет существующая клубная платформа, сначала проверьте её возможности и не дублируйте инфраструктуру без измеримого эффекта.
Как эксплуатировать кэш и что делать при отказе сервера?
Наблюдайте за заполнением тома, журналами, ресурсом SSD, температурой, сетевыми ошибками и доступностью DNS. Сохраняйте .env, Compose-конфигурацию, перечень проверенных образов и план обхода. Кэш содержимого можно восстановить из внешних источников, но сроки повторного прогрева влияют на обслуживание клиентов.
Для аварийного обхода заранее предусмотрите согласованное изменение DNS-маршрута и проверку служебных зон. Учтите TTL и локальные кэши клиентов: переключение DHCP не мгновенно меняет все уже выданные адреса. Не обещайте бесшовный обход, пока он не проверен на реальных ПК.
Доступ к DNS и прокси ограничивают своей сетью. Не выставляйте открытый резолвер или прокси в интернет. После обновления проверяйте старт, монтирование, MISS/HIT, нужные игровые платформы и возможность возврата предыдущей версии. Изменение контейнеров и удаление кэш-тома — разные операции; том не нужно очищать при каждом обновлении.
Как провести недельный пилот до покупки сервера?
Пилот должен ответить на три разных вопроса: сколько внешних байтов удалось не скачивать повторно, насколько изменилось время подготовки игровых мест и какие расходы потребуются для постоянной работы. Высокая скорость одного удачного HIT ещё не отвечает ни на один из них полностью. В выборку включают рабочие дни, массовое обновление популярной игры и повторную установку на нескольких компьютерах.
| Этап | Что сделать | Что сохранить |
|---|---|---|
| До включения | Замерить обычное обновление и загрузку выбранного набора | Версии игр, WAN-байты, время готовности ПК, загрузку портов |
| Холодный кэш | Загрузить тот же набор через новый кэш | MISS, входящий трафик, запись SSD, ошибки и время |
| Повтор на другом ПК | Исключить или отдельно учесть локальный обмен Steam | HIT по байтам, локальную отдачу, WAN и установку |
| Параллельная нагрузка | Повторить типичное число одновременных обновлений | CPU, память, очереди SSD, uplink, время самого медленного клиента |
| Обновление и отказ | Проверить новый контент, перезапуск и согласованный обход | Долю новых блоков, время возврата загрузок, работоспособность DNS |
Не сравнивайте понедельник с одной небольшой игрой и пятницу с десятком крупных обновлений как одинаковую нагрузку. Помимо календарного периода сохраняйте общий запрошенный объём и набор версий. Если точный повтор недоступен, такой результат остаётся наблюдением конкретной недели; из него нельзя честно вывести универсальный процент экономии.
Как отличить недостаток ёмкости от недостатка скорости
При маленьком томе популярные блоки могут вытесняться раньше следующей установки: растёт повторный WAN-трафик, хотя чтение SSD остаётся быстрым. При достаточной ёмкости и слабом uplink будет другая картина: HIT сохраняется, но одновременные клиенты делят узкий канал. В первом случае помогает пересмотр рабочего набора или расширение тома, во втором — изменение сетевого тракта. Покупка большего SSD не расширяет порт коммутатора.
Следите и за местом под логи. Лимит содержимого не означает, что остальные каталоги перестают расти. Например, при условных 2 ГБ журналов в сутки хранение за 30 дней потребует около 60 ГБ до сжатия. Это расчёт для заданного потока, а не норма LanCache: фактический объём измеряют и задают ротацию. Конфигурацию хранения журналов проверяют отдельно от срока жизни кэшируемых блоков.
Как посчитать деньги без обещания быстрой окупаемости
Если тариф безлимитный и его цена не меняется, уменьшение числа скачанных терабайт само по себе не сокращает счёт провайдера. Экономическая ценность может состоять в отсрочке перехода на более дорогой канал, сокращении времени подготовки мест и более ровной работе обновлений. Если канал уже свободен, установки редки, а клиентские диски медленные, отдельная система может оказаться лишней.
Для учебной модели возьмём среднее дополнительное потребление всей системы 150 Вт, круглосуточную работу и условные 10 руб./кВт·ч. Получится 0,15 × 24 × 365 = 1314 кВт·ч и 13 140 руб. в год только на электричество. Здесь нет цены сервера, коммутатора, дисков, охлаждения, сопровождения и замены изношенных SSD. Это не измерение конкретной Supermicro: подставьте показание своего счётчика и тариф.
Стоимость оборудования и внедрения распределяют на выбранный срок эксплуатации, затем добавляют ежегодные расходы. Полученную сумму сопоставляют с реально предотвращёнными расходами и измеримой ценностью освобождённого времени. Если есть только обещание «будет быстрее», а расписание установки не мешает работе зала, основания для дорогой конфигурации пока нет.
Частые вопросы о сервере для компьютерного клуба
Кэш повысит FPS или снизит игровой пинг?
Прямого увеличения FPS нет: игру исполняет клиентский ПК. Снижение нагрузки обновлений на внешний канал может уменьшить конкуренцию за полосу, но задержка игрового соединения зависит от маршрута, очередей и настроек сети. Эффект измеряют отдельно.
Нужно ли хранить отдельную копию игры для каждого компьютера?
Для одинаковых повторно запрашиваемых блоков отдельные полные копии не нужны. Ёмкость определяет уникальный рабочий набор и обновления. Нагрузку чтения определяют параллельные клиенты.
Обязателен ли RAID?
Нет универсального требования. Для восстанавливаемого кэша можно принять риск потери тома, если есть план возврата сервиса. Зеркало помогает пережить отказ диска, но уменьшает полезную ёмкость и не заменяет защиту конфигурации или DNS.
Нужна ли видеокарта в кэш-сервере?
Для обычного DNS/HTTP-кэширования игровой GPU не нужен. Деньги полезнее направить на достаточную память, диски, сеть и обслуживание. Если тот же сервер выполняет другие роли, их требования считают отдельно.
Можно ли запустить LanCache в виртуальной машине?
Да, при наличии подходящего Linux-окружения, выделенного адреса и достаточных ресурсов хранения/сети. Но совместная нагрузка гипервизора и других ВМ может влиять на задержки и пропускную способность. Проверяют фактический тракт и резерв ресурсов.
Первая загрузка станет быстрее интернета?
Нет: отсутствующий в кэше блок сначала должен прийти извне. При выигрыше от других факторов это всё равно отдельное измерение. Основная ценность LanCache — повторная выдача уже сохранённого содержимого.
Что нужно для подбора сервера Supermicro под LanCache?
Подготовьте число игровых мест и одновременных загрузок, скорости клиентских портов и uplink, перечень лаунчеров и игр, объём актуального набора и обновлений, доступный интернет-канал, время обслуживания и допустимый простой. Добавьте схему DNS, сведения о домене AD и существующем сервере клуба.
После короткого пилота станут понятны фактическая доля повторных данных, скорость чтения и узкое место сети. С этими данными можно подобрать конфигурацию Supermicro без лишних CPU и накопителей. Покупка оправдана тогда, когда измеренная экономия времени и ресурсов клуба превышает стоимость системы и её сопровождения.