Разбавляем обычные профили необычными шрифтами в Instagram
Полезный сайт Многие задаются вопросом: как изменить шрифт в шапке инстаграма? И написать там что-то не стандартным...
Открытое программное обеспечение стало основным структурным элементом при создании некоторых крупнейших веб-сайтов. С ростом этих веб-сайтов возникли передовые практические методы и руководящие принципы их архитектуры. Данная глава стремится охватить некоторые ключевые вопросы, которые следует учитывать при проектировании больших веб-сайтов, а также некоторые базовые компоненты, используемые для достижения этих целей.
Основное внимание в данной главе уделяется анализу веб-систем, хотя часть материала может быть экстраполирована и на другие распределенные системы.
Что именно означает создание и управление масштабируемым веб-сайтом или приложением? На примитивном уровне это просто соединение пользователей с удаленными ресурсами через Интернет. А ресурсы или доступ к этим ресурсам, которые рассредоточены на множестве серверов и являются звеном, обеспечивающим масштабируемость веб-сайта.
Как большинство вещей в жизни, время, потраченное заранее на планирование построения веб-службы может помочь в дальнейшем; понимание некоторых соображений и компромиссов, стоящих позади больших веб-сайтов, может принести плоды в виде более умных решений при создании меньших веб-сайтов. Ниже некоторые ключевые принципы, влияющие на проектирование крупномасштабных веб-систем:
Каждый из этих принципов является основой для принятия решений в проектировании распределенной веб-архитектуры. Тем не менее, они также могут находиться в противоречии друг с другом, потому что достижение целей одного происходит за счет пренебрежения другими. Простой пример: выбор простого добавления нескольких серверов в качестве решения производительности (масштабируемость) может увеличивать затраты на управляемость (вы должны эксплуатировать дополнительный сервер) и покупку серверов.
При разработке любого вида веб-приложения важно рассмотреть эти ключевые принципы, даже если это должно подтвердить, что проект может пожертвовать один или больше из них.
При рассмотрении архитектуры системы есть несколько вопросов, которые необходимо осветить, например: какие компоненты стоит использовать, как они совмещаются друг с другом, и на какие компромиссы можно пойти. Вложение денег в масштабирование без очевидной необходимости в ней не может считаться разумным деловым решением. Однако, некоторая предусмотрительность в планировании может существенно сэкономить время и ресурсы в будущем.
Данный раздел посвящается некоторым базовым факторам, которые являются важнейшими для почти всех больших веб-приложений: сервисы
,
избыточность
, сегментирование
, и обработка отказов
. Каждый из этих факторов предполагает выбор и компромиссы, особенно в контексте принципов, описанных в предыдущем разделе. Для пояснения приведем пример.
Вы, вероятно, когда-либо уже размещали изображения в сети. Для больших сайтов, которые обеспечивают хранение и доставку множества изображений, есть проблемы в создании экономически эффективной, высоконадежной архитектуры, которая характеризуется низкими задержками ответов (быстрое извлечение).
Вообразите систему, где пользователи имеют возможность загрузить свои изображения на центральный сервер, и при этом изображения могут запрашиваться через ссылку на сайт или API, аналогично Flickr или Picasa. Для упрощения описания давайте предположим, что у этого приложения есть две основные задачи: возможность загружать (записывать) изображения на сервер и запрашивать изображения. Безусловно, эффективная загрузка является важным критерием, однако приоритетом будет быстрая доставка по запросу пользователей (например, изображения могут быть запрошены для отображения на веб-странице или другим приложением). Эта функциональность аналогична той, которую может обеспечить веб-сервер или граничный сервер Сети доставки контента (Content Delivery Network, CDN). Сервер CDN обычно хранит объекты данных во многих расположениях, таким образом, их географическое/физическое размещение оказывается ближе к пользователям, что приводит к росту производительности.
Другие важные аспекты системы:
Другая потенциальная проблема с этим дизайном состоит в том, что у веб-сервера, такого как Apache или lighttpd обычно существует верхний предел количества одновременных соединений, которые он в состоянии обслужить (значение по умолчанию - приблизительно 500, но оно может быть намного выше), и при высоком трафике записи могут быстро израсходовать этот предел. Так как чтения могут быть асинхронными или использовать в своих интересах другую оптимизацию производительности как gzip-сжатие или передача с делением на порции, веб-сервер может переключить чтения подачи быстрее и переключиться между клиентами, обслуживая гораздо больше запросов, чем максимальное число соединений (с Apache и максимальным количеством соединений, установленном в 500, вполне реально обслуживать несколько тысяч запросов чтения в секунду). Записи, с другой стороны, имеют тенденцию поддерживать открытое соединение на протяжении всего времени загрузки. Так передача файла размером 1 МБ на сервер могла занять больше 1 секунды в большинстве домашних сетей, в результате веб-сервер сможет обработать только 500 таких одновременных записей.
Рисунок 1.2: Разделение чтения и записи
Предвидение подобной потенциальной проблемы свидетельствует о необходимости разделения чтения и записи изображений в независимые службы, показанные на . Это позволит не только масштабировать каждую из них по отдельности (так как вероятно, что мы будем всегда делать больше чтений, чем записей), но и быть в курсе того, что происходит в каждой службе. Наконец, это разграничит проблемы способные возникнуть в будущем, что упростит диагностику и оценку проблемы медленного доступа на чтение.
Преимущество этого подхода состоит в том, что мы в состоянии решить проблемы независимо друг от друга - при этом нам не придется думать о необходимости записи и получении новых изображений в одном контексте. Обе из этих служб все еще используют глобальный корпус изображений, но при использовании методов соответствующих определенной службе, они способны оптимизировать свою собственную производительность (например, помещая запросы в очередь, или кэшируя популярные изображения - более подробно об этом речь пойдет далее). Как с точки зрения обслуживания, так и стоимости каждая служба может быть масштабирована независимо по мере необходимости. И это является положительным фактором, поскольку их объединение и смешивание могло бы непреднамеренно влиять на их производительность, как в сценарии, описанном выше.
Конечно, работа вышеупомянутой модели будет оптимальной, в случае наличия двух различных конечных точек (фактически, это очень похоже на несколько реализаций провайдеров «облачного» хранилища и Сетей доставки контента). Существует много способов решения подобных проблем, и в каждом случае можно найти компромисс.
К примеру, Flickr решает эту проблему чтения-записи, распределяя пользователи между разными модулями, таким образом, что каждый модуль может обслуживать только ограниченное число определенных пользователей, и когда количество пользователи увеличиваются, больше модулей добавляется к кластеру (см. презентацию масштабирования Flickr,
http://mysqldba.blogspot.com/2008/04/mysql-uc-2007-presentation-file.html). В первом примере проще масштабировать аппаратные средства на основе фактической нагрузки использования (число чтений и записей во всей системе), тогда как масштабировние Flickr просиходит на основе базы пользователей(однако, здесь используется предположение равномерного использования у разных пользователей, таким образом, мощность нужно планировать с запасом). В прошлом недоступность или проблема с одной из служб приводили в нерабочее состояние функциональность целой системы (например, никто не может записать файлы), тогда недоступность одного из модулей Flickr будет влиять только на пользователей, относящихся к нему. В первом примере проще выполнить операции с целым набором данных - например, обновляя службу записи, чтобы включить новые метаданные, или выполняя поиск по всем метаданным изображений - тогда как с архитектурой Flickr каждый модуль должен был быть подвергнут обновлению или поиску (или поисковая служба должна быть создана, чтобы сортировать те метаданные, которые фактически для этого и предназначены).
Что касается этих систем - не существует никакой панацеи, но всегда следует исходить из принципов, описанных в начале этой главы: определить системные потребности (нагрузка операциями «чтения» или «записи» или всем сразу, уровень параллелизма, запросы по наборам данных, диапазоны, сортировки, и т.д.), провести сравнительное эталонное тестирование различных альтернатив, понять условия потенциального сбоя системы и разработать комплексный план на случай возникновения отказа.
Чтобы элегантно справится с отказом, у веб-архитектуры должна быть избыточность ее служб и данных. Например, в случае наличия лишь одной копии файла, хранившегося на единственном сервере, потеря этого сервера будет означать потерю и файла. Вряд ли подобную ситуацию можно положительно охарактеризовать, и обычно ее можно избежать путем создания множественных или резервных копии.
Этот тот же принцип применим и к службам. От отказа единственного узла можно защититься, если предусмотреть неотъемлемую часть функциональности для приложения, гарантирующую одновременную работу его нескольких копий или версий.
Создание избыточности в системе позволяет избавиться от слабых мест и обеспечить резервную или избыточную функциональность на случай нештатной ситуации. Например, в случае наличия двух экземпляров одной и той же службы, работающей в «продакшн», и один из них выходит из строя полностью или частично, система может преодолеть отказ за счет переключения на исправный экземпляр
.
Переключение может происходить автоматически или потребовать ручного вмешательства..
Другая ключевая роль избыточности службы - создание архитектуры, не предусматривающей разделения ресурсов . С этой архитектурой каждый узел в состоянии работать самостоятельно и, более того, в отсутствие центрального «мозга», управляющего состояниями или координирующего действия других узлов. Она способствует масштабируемости, так как добавление новых узлов не требует специальных условий или знаний. И что наиболее важно, в этих системах не найдется никакой критически уязвимой точки отказа, что делает их намного более эластичными к отказу..
Например, в нашем приложении сервера изображения, все изображения имели бы избыточные копии где-нибудь в другой части аппаратных средств (идеально - с различным географическим местоположением в случае такой катастрофы, как землетрясение или пожар в центре обработки данных), и службы получения доступа к изображениям будут избыточны, при том, что все они потенциально будут обслуживать запросы. (См. .)
Забегая вперед, балансировщики нагрузки - отличный способ сделать это возможным, но подробнее об этом ниже.
Рисунок 1.3: Приложение хостинга изображений с избыточностью
Наборы данных могут быть настолько большими, что их невозможно будет разместить на одном сервере. Может также случиться, что вычислительные операции потребуют слишком больших компьютерных ресурсов, уменьшая производительность и делая необходимым увеличение мощности. В любом случае у вас есть два варианта: вертикальное или горизонтальное масштабирование.
Вертикальное масштабирование предполагает добавление большего количества ресурсов к отдельному серверу. Так, для очень большого набора данных это означало бы добавление большего количества (или большего объема) жестких дисков, и таким образом весь набор данных мог бы разместиться на одном сервере. В случае вычислительных операций это означало бы перемещение вычислений в более крупный сервер с более быстрым ЦП или большим количеством памяти. В любом случае, вертикальное масштабирование выполняется для того, чтобы сделать отдельный ресурс вычислительной системы способным к дополнительной обработке данных.
Горизонтальное масштабирование, с другой стороны, предполагает добавление большего количества узлов. В случае большого набора данных это означало бы добавление второго сервера для хранения части всего объема данных, а для вычислительного ресурса это означало бы разделение работы или загрузки через некоторые дополнительные узлы. Чтобы в полной мере воспользоваться потенциалом горизонтального масштабирования, его необходимо реализовать как внутренний принцип разработки архитектуры системы. В противном случае изменение и выделение контекста, необходимого для горизонтального масштабирования может оказаться проблематичным.
Наиболее распространенным методом горизонтального масштабирования считается разделение служб на сегменты или модули. Их можно распределить таким образом, что каждый логический набор функциональности будет работать отдельно. Это можно сделать по географическими границами, или другим критериям таким, как платящие и не платящие пользователи. Преимущество этих схем состоит в том, что они предоставляют услугу или хранилище данных с расширенной функциональностью.
В нашем примере сервера изображения, возможно, что единственный файловый сервер, используемый для хранения изображения, можно заменить множеством файловых серверов, при этом каждый из них будет содержать свой собственный уникальный набор изображений. (См. .) Такая архитектура позволит системе заполнять каждый файловый сервер изображениями, добавляя дополнительные серверы, по мере заполнения дискового пространства. Дизайн потребует схемы именования, которая свяжет имя файла изображения с содержащим его сервером. Имя изображения может быть сформировано из консистентной схемы хеширования, привязанной к серверам. Или альтернативно, каждое изображение может иметь инкрементный идентификатор, что позволит службе доставки при запросе изображения обработать только диапазон идентификаторов, привязанных к каждому серверу (в качестве индекса).
Рисунок 1.4: Приложение хостинга изображений с избыточностью и сегментированием
Конечно, есть трудности в распределении данных или функциональности на множество серверов. Один из ключевых вопросов - местоположение данных ; в распределенных системах, чем ближе данные к месту проведения операций или точке вычисления, тем лучше производительность системы. Следовательно, распределение данных на множество серверов потенциально проблематично, так как в любой момент, когда эти данные могут понадобиться, появляется риск того, что их может не оказаться по месту требования, серверу придется выполнить затратную выборку необходимой информации по сети.
Другая потенциальная проблема возникает в форме
несогласованности (неконсистетности)
.Когда различные сервисы выполняют считывание и запись на совместно используемом ресурсе, потенциально другой службе или хранилище данных, существует возможность возникновения условий «состязания» - где некоторые данные считаются обновленными до актуального состояния, но в реальности их считывание происходит до момента актуализации - и таком случае данные неконсистентны. Например, в сценарии хостинга изображений, состояние состязания могло бы возникнуть в случае, если бы один клиент отправил запрос обновления изображения собаки с изменением заголовка «Собака» на «Гизмо», в тот момент, когда другой клиент считывал изображение. В такой ситуации неясно, какой именно заголовок, «Собака» или «Гизмо», был бы получен вторым клиентом..
Есть, конечно, некоторые препятствия, связанные с сегментированием данных, но сегментирование позволяет выделять каждую из проблем из других: по данным, по загрузке, по образцам использования, и т.д. в управляемые блоки. Это может помочь с масштабируемостью и управляемостью, но риск все равно присутствует. Есть много способов уменьшения риска и обработки сбоев; однако, в интересах краткости они не охвачены в этой главе. Если Вы хотите получить больше информации по данной теме, вам следует взглянуть на блог-пост по отказоустойчивости и мониторингу.
Рассмотрев некоторые базовые принципы в разработке распределенных систем, давайте теперь перейдем к более сложному моменту - масштабирование доступа к данным.
Самые простые веб-приложения, например, приложения стека LAMP, схожи с изображением на .
Рисунок 1.5: Простые веб-приложения
С ростом приложения возникают две основных сложности: масштабирование доступа к серверу приложений и к базе данных. В хорошо масштабируемом дизайне приложений веб-сервер или сервер приложений обычно минимизируется и часто воплощает архитектуру, не предусматривающую совместного разделения ресурсов. Это делает уровень сервера приложений системы горизонтально масштабируемым. В результате использовании такого дизайна тяжёлый труд сместится вниз по стеку к серверу базы данных и вспомогательным службам; именно на этом слое и вступают в игру настоящие проблемы масштабирования и производительности.
Остальная часть этой главы посвящена некоторым наиболее распространенным стратегиям и методам повышения производительности и обеспечения масштабируемости подобных типов служб путем предоставления быстрого доступа к данным.
Рисунок 1.6: Упрощенное веб-приложение
Большинство систем может быть упрощено до схемы на ,
которая является хорошей отправной точкой для начала рассмотрения. Если у Вас есть много данных, можно предположить, что Вы хотите иметь к ним такой же легкий доступ и быстрый доступ, как к коробке с леденцами в верхнем ящике вашего стола. Хотя данное сравнение чрезмерно упрощено, оно указывает на две сложные проблемы: масштабируемость хранилища данных и быстрый доступ к данным.
Для рассмотрения данного раздела давайте предположим, что у Вас есть много терабайт (ТБ) данных, и Вы позволяете пользователям получать доступ к небольшим частям этих данных в произвольном порядке. (См. .)
Схожей задачей является определение местоположения файла изображения где-нибудь на файловом сервере в примере приложения хостинга изображений.
Рисунок 1.7: Доступ к определенным данным
Это особенно трудно, потому что загрузка терабайтов данных в память может быть очень накладной и непосредственно влияет на количество дисковых операций ввода-вывода. Скорость чтения с диска в несколько раз ниже скорости чтения из оперативной памяти - можно сказать, что доступ к памяти с так же быстр, как Чак Норрис, тогда как доступ к диску медленнее очереди в поликлинике. Эта разность в скорости особенно ощутима для больших наборов данных; в сухих цифрах доступ к памяти 6 раз быстрее, чем чтение с диска для последовательных операций чтения, и в 100,000 раз - для чтений в случайном порядке (см. «Патологии Больших Данных», http://queue.acm.org/detail.cfm?id=1563874).). Кроме того, даже с уникальными идентификаторами, решение проблемы нахождения местонахождения небольшой порции данных может быть такой же трудной задачей, как и попытка не глядя вытащить последнюю конфету с шоколадной начинкой из коробки с сотней других конфет.
К счастью существует много подходов, которые можно применить для упрощения, из них четыре наиболее важных подхода - это использование кэшей, прокси, индексов и балансировщиков нагрузки. В оставшейся части этого раздела обсуждается то, как каждое из этих понятий может быть использовано для того, чтобы сделать доступ к данным намного быстрее.
Кэширование дает выгоду за счет характерной черты базового принципа: недавно запрошенные данные вполне вероятно потребуются еще раз. Кэши используются почти на каждом уровне вычислений: аппаратные средства, операционные системы, веб-браузеры, веб-приложения и не только. Кэш походит на кратковременную память: ограниченный по объему, но более быстрый, чем исходный источник данных, и содержащий элементы, к которым недавно получали доступ. Кэши могут существовать на всех уровнях в архитектуре, но часто находятся на самом близком уровне к фронтэнду, где они реализованы, чтобы возвратить данные быстро без значительной нагрузки бэкэнда.
Каким же образом кэш может использоваться для ускорения доступа к данным в рамках нашего примера API? В этом случае существует несколько мест, подходящих размещения кэша. В качестве одного из возможных вариантов размещения можно выбрать узлы на уровне запроса, как показано на
.
Рисунок 1.8: Размещение кэша на узле уровня запроса
Размещение кэша непосредственно на узле уровня запроса позволяет локальное хранение данных ответа. Каждый раз, когда будет выполняться запрос к службе, узел быстро возвратит локальные, кэшированные данные, если таковые существуют. Если это не будет в кэше, то узел запроса запросит данные от диска. Кэш на одном узле уровня запроса мог также быть расположен как в памяти (которая очень быстра), так и на локальном диске узла (быстрее, чем попытка обращения к сетевому хранилищу).
Рисунок 1.9: Системы кэшей
Что происходит, когда вы распространяете кеширование на множество узлов? Как Вы видите , если уровень запроса будет включать множество узлов, то вполне вероятно, что каждый узел будет и свой собственный кэш. Однако, если ваш балансировщик нагрузки в произвольном порядке распределит запросы между узлами, то тот же запрос перейдет к различным узлам, таким образом увеличивая неудачные обращения в кэш. Двумя способами преодоления этого препятствия являются глобальные и распределенные кэши.
Смысл глобального кэша понятен из названия: все узлы используют одно единственное пространство кэша. В этом случае добавляется сервер или хранилище файлов некоторого вида, которые быстрее, чем Ваше исходное хранилище и, которые будут доступны для всех узлов уровня запроса. Каждый из узлов запроса запрашивает кэш таким же образом, как если бы он был локальным. Этот вид кэширующей схемы может вызвать некоторые затруднения, так как единственный кэш очень легко перегрузить, если число клиентов и запросов будет увеличиваться. В тоже время такая схема очень эффективна при определенной архитектуре (особенно связанной со специализированными аппаратными средствами, которые делают этот глобальный кэш очень быстрым, или у которых есть фиксированный набор данных, который должен кэшироваться).
Есть две стандартных формы глобальных кэшей, изображенных в схемах. На изображена ситуация, когда кэшируемый ответ не найден в кэше, сам кэш становится ответственным за получение недостающей части данных от базового хранилища. На проиллюстрирована обязанность узлов запроса получить любые данные, которые не найдены в кэше.
Рисунок 1.10: Глобальный кэш, где кэш ответственен за извлечение
Рисунок 1.11: Глобальный кэш, где узлы запроса ответственны за извлечение
Большинство приложений, усиливающих глобальные кэши, склонно использовать первый тип, где сам кэш управляет замещением и данными выборки, чтобы предотвратить лавинную рассылку запросов на те же данные от клиентов. Однако, есть некоторые случаи, где вторая реализация имеет больше смысла. Например, если кэш используется для очень больших файлов, низкий процент удачного обращения в кэш приведет к перегрузке кэша буфера неудачными обращениями в кэш; в этой ситуации это помогает иметь большой процент общего набора данных (или горячего набора данных) в кэше. Другой пример - архитектура, где файлы, хранящиеся в кэше, статичны и не должны быть удалены. (Это может произойти из-за основных эксплуатационных характеристик касательно такой задержки данных - возможно, определенные части данных должны оказаться очень быстрыми для больших наборов данных - когда логика приложения понимает стратегию замещения или горячие точки лучше, чем кэш.)
Данные индексы часто хранятся в памяти или где-нибудь очень локально по отношению к входящему запросу клиента. Berkeley DB (BDB) и древовидные структуры данных, которые обычно используются, чтобы хранить данные в упорядоченных списках, идеально подходят для доступа с индексом.
Часто имеется много уровней индексов, которые служат картой, перемещая вас от одного местоположения к другому, и т.д., до тех пор пока вы не получите ту часть данных, которая вам необходима. (См. )
Рисунок 1.17: Многоуровневые индексы
Индексы могут также использоваться для создания нескольких других представлений тех же данных. Для больших наборов данных это - отличный способ определить различные фильтры и виды, не прибегая к созданию многих дополнительных копий данных.
Например, предположим, что система хостинга изображений, упомянутая выше, на самом деле размещает изображения книжных страниц, и сервис обеспечивает возможность клиентских запросов по тексту в этих изображениях, ища все текстовое содержимое по заданной теме также, как поисковые системы позволяют вам искать по HTML-содержимому. В этом случае все эти книжные изображения используют очень много серверов для хранения файлов, и нахождение одной страницы для представления пользователю может быть достаточно сложным. Изначально обратные индексы для запроса произвольных слов и наборов слов должны быть легкодоступными; тогда существует задача перемещения к точной странице и месту в этой книге и извлечения правильного изображения для результатов поиска. Таким образом, в этом случае инвертированный индекс отобразился бы на местоположении (таком как книга B), и затем B может содержать индекс со всеми словами, местоположениями и числом возникновений в каждой части.
Инвертированный индекс, который может отобразить Index1 в схеме выше, будет выглядеть примерно так: каждое слово или набор слов служат индексом для тех книг, которые их содержат.
Промежуточный индекс будет выглядеть похоже, но будет содержать только слова, местоположение и информацию для книги B. Такая содержащая несколько уровней архитектура позволяет каждому из индексов занимать меньше места, чем, если бы вся эта информация была сохранена в один большой инвертированный индекс.
И это ключевой момент в крупномасштабных системах, потому что даже будучи сжатыми, эти индексы могут быть довольно большими и затратными для хранения. Предположим, что у нас есть много книг со всего мира в этой системе, - 100,000,000 (см. запись блога «Внутри Google Books»)- и что каждая книга состоит только из 10 страниц (в целях упрощения расчетов) с 250 словами на одной странице: это суммарно дает нам 250 миллиардов слов. Если мы принимаем среднее число символов в слове за 5, и каждый символ закодируем 8 битами (или 1 байтом, даже при том, что некоторые символы на самом деле занимают 2 байта), потратив, таким образом, по 5 байтов на слово, то индекс, содержащий каждое слово только один раз, потребует хранилище емкостью более 1 терабайта. Таким образом, вы видите, что индексы, в которых есть еще и другая информация, такая, как наборы слов, местоположение данных и количества употреблений, могут расти в объемах очень быстро.
Создание таких промежуточных индексов и представление данных меньшими порциями делают проблему «больших данных» более простой в решении. Данные могут быть распределены на множестве серверов и в то же время быть быстродоступны. Индексы - краеугольный камень информационного поиска и база для сегодняшних современных поисковых систем. Конечно, этот раздел лишь в общем касается темы индексирования, и проведено множество исследований о том, как сделать индексы меньше, быстрее, содержащими больше информации (например, релевантность), и беспрепятственно обновляемыми. (Существуют некоторые проблемы с управляемостью конкурирующими условиями, а также с числом обновлений, требуемых для добавления новых данных или изменения существующих данных, особенно в случае, когда вовлечены релевантность или оценка).
Очень важна возможность быстро и легко найти ваши данные, и индексы - самый простой и эффективный инструмент для достижения этой цели.
Наконец, другая критически важная часть любой распределенной системы - балансировщик нагрузки. Балансировщики нагрузки - основная часть любой архитектуры, поскольку их роль заключается в распределении нагрузки между узлами, ответственными за обслуживание запросов. Это позволяет множеству узлов прозрачно обслуживать одну и ту же функцию в системе. (См. .) Их основная цель состоит в том, чтобы обрабатывать много одновременных соединений и направлять эти соединения к одному из запрашиваемых узлов, позволяя системе масштабироваться, просто добавляя узлы, чтобы обслужить большее количество запросов.
Рисунок 1.18: Балансировщик нагрузки
Существует много различных алгоритмов для обслуживания запросов, включая выбор случайного узла, циклического алгоритма или даже выбор узла на основе определенных критериев, таких как использование центрального процессора или оперативной памяти. Балансировщики нагрузки могут быть реализованы как аппаратные устройства или программное обеспечение. Среди балансировщиков нагрузки на программном обеспечении с открытым исходным кодом наиболее широкое распространение получил HAProxy .
В распределенной системе балансировщики нагрузки часто находятся на «переднем краю» системы, так что все входящие запросы проходят непосредственно через них. Весьма вероятно, что в сложной распределенной системе запросу придется пройти через несколько балансировщиков, как показано на
.
Рисунок 1.19: Множественные балансировщики нагрузки
Как и прокси, некоторые балансировщики нагрузки могут также направлять запросы по-разному, в зависимости от типа запроса. Они также известны как реверсивные (обратные) прокси.
Управление данными, специфичными для определенного сеанса пользователя, является одной из проблем при использовании балансировщиков нагрузок. На сайте электронной коммерции, когда у Вас есть только один клиент, очень просто позволить пользователям помещать вещи в свою корзину и сохранять ее содержимое между визитами (это важно, так как вероятность продажи товара значительно возрастает, если по возвращении пользователя на сайт, продукт все еще находится в его корзине). Однако если пользователь направлен к одному узлу для первого сеанса, и затем к другому узлу во время его следующего посещения, то могут возникать несоответствия, так как новый узел может не иметь данных относительно содержимого корзины этого пользователя. (Разве вы не расстроитесь, если поместите упаковку напитка Mountain Dew в Вашу корзину, и, когда вернетесь, ее там уже не будет?) Одно из решений может состоять в том, чтобы сделать сеансы «липкими», так чтобы пользователь был всегда направлен к тому же узлу. Однако использование в своих интересах некоторых функций надежности, таких как автоматическая отказоустойчивость, будет существенно затруднено. В этом случае корзина пользователя всегда будет иметь содержание, но если их липкий узел станет недоступным, то будет необходим особый подход, и предположение о содержании корзины не будет больше верно (хотя, стоит надеяться, что это предположение не будет встроено в приложение). Конечно, данную проблему можно решить при помощи других стратегий и инструментов, как описанных в этой главе, таких как службы, так и многих других (как кэши браузера, cookie и перезапись URL).
Если у системы только несколько узлов, то такие приемы, как DNS-карусель, скорее всего окажутся более практичными, чем балансировщики загрузки, которые могут быть дорогими и увеличивать сложность системы добавлением ненужного уровня. Конечно, в больших системах есть все виды различных алгоритмов планирования и выравнивания нагрузки, включая как простые вроде случайного выбора или карусельного алгоритма, так и более сложные механизмы, которые принимают во внимание производительность особенности модели использования системы. Все эти алгоритмы позволяют распределить трафик и запросы, и могут обеспечить полезные инструменты надежности, такие как автоматическая отказоустойчивость или автоматическое удаление поврежденного узла (например, когда он перестает отвечать на запросы). Однако, эти расширенные функции могут сделать диагностику проблем громоздкой. Например, в ситуациях с высокой нагрузкой, балансировщики нагрузки будут удалять узлы, которые могут работать медленно или превышать время ожидания (из-за шквала запросов), что только усугубит ситуацию для других узлов. В этих случаях важен обширный контроль потому, что даже если кажется, что полный системный трафик и нагрузка снижаются (так как узлы обслуживают меньшее количество запросов) - отдельные узлы могут оказаться нагруженными до предела.
Балансировщики нагрузки - это простой способ нарастить мощность системы. Как и другие методы, описанные в этой статье, он играет существенную роль в архитектуре распределенной системы. Балансировщики нагрузки также обеспечивают критическую функцию проверки работоспособности узлов. Если по результатам такой проверки узел не отвечает или перегружен, то он может быть удален из пула обработки запросов, и, благодаря избыточности Вашей системы, нагрузка будет перераспределена между оставшимися рабочими узлами.
До сих пор нами было рассмотрено множество способов быстрого считывания данных. В то же время еще одной важной частью масштабирования уровня данных является эффективное управление записями. Когда системы просты и характеризуются минимальными загрузками обработки и маленькими базами данных, запись может быть предсказуемо быстра. Однако, в более сложных системах данный процесс может занять неопределенно длительное время. Так, например, данные, возможно, придется записать в нескольких местах на различных серверах или индексах, или система может просто находится под высокой нагрузкой. В тех случаях, когда записи или даже просто любая задача занимают длительное время, достижение производительности и доступности требует встраивания асинхронности в систему. Распространенный способ сделать это - организовать очередь запросов.
Рисунок 1.20: Синхронный запрос
Представьте себе систему, в которой каждый клиент запрашивает задачу удаленного обслуживания. Каждый из этих клиентов отправляет свой запрос серверу, который выполняет задачи как можно быстрее и возвращает их результаты соответствующим клиентам. В маленьких системах, где один сервер (или логическая служба) может обслуживать поступающих клиентов так же быстро, как они прибывают, ситуации такого рода должны работать нормально. Однако, когда сервер получает больше запросов, чем он может обработать, тогда каждый клиент вынужден ожидать завершения обработки запросов других клиентов, прежде чем ответ на его собственный запрос будет сгенерирован. Это - пример синхронного запроса, изображенного на .
Такой вид синхронного поведения может значительно ухудшить производительность клиента; фактически простаивая, клиент вынужден ожидать, пока не получит ответ на запрос. Добавление дополнительных серверов с целью справиться с нагрузкой системы, по сути, не решает проблемы; даже с эффективным выравниванием нагрузки на месте, чрезвычайно трудно обеспечить равномерное и справедливое распределение нагрузки необходимое для максимизации производительности клиента. Более того, если сервер для обработки этого запроса недоступен (или он вышел из строя), то клиент, подключенный к нему, также перестанет работать. Эффективное решение этой проблемы требует абстракции между запросом клиента и фактической работой, выполняемой для его обслуживания.
Рисунок 1.21: Использование очередей для управления запросами
Очереди входа. Механизм работы очереди очень прост: задача приходит, попадает в очередь, и затем «рабочие» принимают следующую задачу, как только у них появляется возможность обработать ее. (См. .) Эти задачи могут представлять собой простые записи в базу данных или что-то столь же сложное как генерация изображения предварительного просмотра для документа. Когда клиент отправляет запросы постановки задач в очередь, ему больше не требуется ожидать результатов выполнения; вместо этого запросы нуждаются только в подтверждении факта их получения должным образом. Это подтверждение может позже служить ссылкой на результаты работы, когда клиент затребует их.
Очереди позволяют клиентам работать асинхронным способом, обеспечивая стратегическую абстракцию запроса клиента и ответа на него. С другой стороны, в синхронной системе, нет никакого дифференцирования между запросом и ответом, и поэтому ими нельзя управлять отдельно. В асинхронной системе клиент ставит задачу, служба отвечает сообщением, подтверждая, что задача была получена, и затем клиент может периодически проверять состояние задачи, только запрашивая результат, как только это завершилось. В то время как клиент выполнения асинхронного запроса, он свободен для того, чтобы заниматься другой работой, и даже выполнять асинхронные запросы других служб. Последнее - это пример того, как очереди и сообщения работают в распределенных системах.
Очереди также обеспечивают некоторую защиту от приостановок обслуживания и отказов. Например, довольно просто создать очень устойчивую очередь, которая может повторить запросы на обслуживание, которые перестали работать из-за кратковременных отказов сервера. Более предпочтительно использовать очередь, чтобы реализовывать гарантии качества обслуживания, чем показывать клиентам временные перебои в работе сервиса, требуя сложной и часто противоречивой обработки ошибок на стороне клиентов.
Разработка эффективных систем с быстрым доступом к большому количеству данных является очень интересной темой, и существует еще значительное число хороших инструментов, которые позволяют адаптировать все виды новых приложений. Эта глава коснулась всего лишь нескольких примеров, но в реальности их гораздо больше - и создание новых инноваций в этой области будет только продолжаться.
Эта работа распространяется под неизменённой лицензией Creative Commons Attribution 3.0 . См. подробности в
Эти проблемы возникли из-за выбора архитектуры, который был сделан при создании системы регулирования заторов TCP в 80-е годы - тогда потерю пакетов решили интерпретировать как «затор». Эквивалентность этих понятий была справедливой для того времени, но только из-за ограничений технологии, а не по определению. Когда NIC (контроллеры сетевых интерфейсов) модернизировали с мегабитных до гигабитных скоростей, а микросхемы памяти - с килобайт до гигабайт, до связь между потерей пакетов и заторами стала менее очевидной.
В современном TCP регулирование заторов по потере пакетов - даже в наиболее совершенной технологии такого рода CUBIC - основная причина этих проблем. Если буферы узких мест слишком большие, то система регулирования заторов по потере пакетов держит их полными, вызывая излишнюю сетевую буферизацию. Если буферы слишком маленькие, то система регулирования заторов по потере пакетов неверно интерпретирует потерю пакета как сигнал затора, что ведёт к снижению пропускной способности. Решение этих проблем требует альтернативы регулированию заторов по потере пакетов. Для нахождения этой альтернативы следует разобраться, где и как возникают заторы.
На иллюстрации 1 показаны разнообразные сочетания RTT и скорости передачи с объёмом данных в полёте , то есть inflight (данные отправлены, но без подтверждения доставки). Синие линии показывают ограничение RTprop, зелёные линии - ограничение BtlBw, а красные линии - буфер узкого места. Операции в серых областях невозможны, поскольку противоречат хотя бы одному ограничению. Переходы между ограничениями привели к образованию трёх районов (app-limited, bandwidth-limited и buffer-limited) с качественно разным поведением.
Рисунок 1
Когда в полёте недостаточно данных, чтобы заполнить трубу, RTprop определяет поведение; в противном случае доминирует BtlBw. Линии ограничения пересекаются в точке , она же BDP трубы (bandwidth-delay product, производное пропускной способности и задержки). Поскольку труба полная после этой точки, то излишек создаёт очередь к узкому месту, что приводит к линейной зависимости RTT от данных inflight, показанной на верхнем графике. Пакеты отбрасываются, когда излишек превышает вместимость буфера. Затор - это просто непрерывное нахождение справа от линии BDP, а регулирование заторов - некая схема для установления ограничения, как далеко справа от линии BDP, в среднем, происходит передача данных.
Регулирование заторов по потерям работает на правой границе района, ограниченного пропускной способностью канала (bandwidth-limited), обеспечивая полную пропускную способность узкого места за счёт больших задержек и частой потери пакетов. В те времена, когда память была дорога, размеры буфера лишь немного превышали BDP, что минимизировало избыточную задержку регулирования заторов по потерям. Последующие снижения цен на память привели к увеличению излишней сетевой буферизации и росту RTT до секунд вместо миллисекунд.
На левом краю района, ограниченного пропускной способностью канала, есть рабочая точка с лучшими условиями, чем справа. В 1979 году Леонард Клейнрок показал, что данная рабочая точка оптимальна, она максимизирует фактическую пропускную способность с минимизацией задержек и потерь, как для отдельных соединений, так и для сети в целом . К сожалению, примерно в то же время Джеффри Яффе доказал, что невозможно создать распределённый алгоритм, который сходится в этой рабочей точке. Этот вывод изменил направление исследований. Вместо поиска распределённого алгоритма, который стремится к оптимальной рабочей точки Клейнрока, исследователи начали изучать альтернативные подходы к регулированию заторов.
Наша группа в компании Google каждый день тратит часы на изучение логов с перехватами заголовков пакетов TCP со всего мира, осмысляя аномалии и патологии поведения. Обычно мы первым делом ищем ключевые характеристики маршрута, RTprop и BtlBw. То, что их можно вывести из сетевых трейсов, позволяет предположить, что вывод Яффе мог быть не таким однозначным, как когда-то казалось. Его вывод полагается на фундаментальную неопределённость измерения (например, будь измеренное увеличение RTT вызвано изменением длины пути, уменьшением пропускной способности узкого места или увеличением задержки в очереди из-за трафика от другого соединения). Хотя невозможно устранить неопределённость каждого конкретного измерения, но поведение соединения во времени даёт более ясную картину, подсказывая возможность применения стратегий измерений, созданных для устранения неопределённости.
Совместив эти измерения с надёжным следящим контуром, применив последние достижения в системах управления , можно надеяться на разработку распределённого протокола регулирования заторов, который реагирует на действительный затор, а не на потерю пакетов или кратковременную задержку в очереди. И он будет с высокой вероятностью сходиться в оптимальной рабочей точке Клейнрока. Так начался наш трёхлетний проект по разработке системы управления заторами на основе измерения двух параметров, которые характеризуют маршрут: пропускной способности узкого места и времени двойного прохода пакета, или BBR.
Первое условие гарантирует, что узкое место используется на 100%. Второе гарантирует, что у нас достаточно данных, чтобы предотвратить простой узкого места, но не переполнить канал. Условие баланса скорости само по себе не гарантирует отсутствия очереди, только её неизменный размер (например, если соединение начинается с отправки 10-пакетного Initial Window в пятипакетный BDP, затем работает в точности на одинаковой скорости узкого места, то пять из десяти начальных пакетов заполнят канал, а излишек сформирует стоячую очередь в узком месте, которая не сможет рассосаться). Точно так же, условие полного канала не гарантирует отсутствия очереди (например, соединение отправляет BDP всплесками по BDP/2 и полностью использует узкое место, но но средняя очередь составляет BDP/4). Единственный способ минимизировать очередь в узком месте и по всему каналу - это соответствовать обоим условиям одновременно.
Значения BtlBw и RTprop изменяются в течение срока жизни соединения, так что их следует постоянно оценивать. В настоящее время TCP отслеживает RTT (интервал времени между отправкой пакета данных до сообщения о его доставке), потому что это требуется для определения потерь. В любой момент времени ,
В отличие от RTT, ничто в спецификациях TCP не требует реализации для отслеживания пропускной способности узкого места, но хорошую оценку этого можно получить из отслеживания скорости доставки. Когда подтверждение о доставке какого-то пакета возвращается к отправителю, оно показывает RTT пакета и анонсирует доставку данных в полёте, когда пакет отбывает. Средняя скорость доставки между отправкой пакета и получением подтверждения - это отношение доставленных данных к прошедшему времени: . Эта скорость должна быть меньше или равна пропускной способности узкого места (количество по прибытию точно известно, так что вся неопределённость заключается в , которая должна быть больше или равна настоящему интервалу прибытия; поэтому отношение должно быть меньше или равно настоящей скорости доставки, которое, в свою очередь, ограничено сверху ёмкостью узкого места). Следовательно, максимальное окно скорости доставки - это эффективная, беспристранстная оценка BtlBw:
TCP должен записать время отправки каждого пакета, чтобы вычислить RTT. BBR дополняет эти записи общим количеством доставленных данных, так что прибытие каждого подтверждения сообщает одновременно и RTT, и результат измерения скорости доставки, которую фильтры преобразуют в оценки RTprop и BtlBw.
Заметьте, что эти значения полностью независимы: RTprop может изменяться (например, при изменении маршрута), но обладает тем же узким местом, или BtlBw может изменяться (например, когда меняется пропускная способность беспроводного канала) без изменения маршрута. (Независимость обеих сдерживающих факторов - там причина, почему они должны быть известны, чтобы связать поведение при отправке с маршрутом доставки). Поскольку RTprop виден только с левой стороны BDP, а BtlBw - только с правой стороны на рисунке 1, то они подчиняются принципу неопределённости: всякий раз, когда одно из двух можно измерить, второе измерить невозможно. Интуитивно это можно понять следующим образом: чтобы определить ёмкость канала, его нужно переполнить, что создаёт очередь, которая не даёт возможность измерить длину канала. Например, приложение с протоколом запросов/ответов может никогда не отправить достаточно данных для заполнения канала и наблюдения BtlBw. Многочасовая передача большого массива данных может всё своё время потратить в районе с ограниченной пропускной способностью и получить только единственный образец RTprop от RTT у первого пакета. Присущий принцип неопределённости означает, что вдобавок к оценкам для восстановления двух параметров маршрута, должны быть такие состояния, которые отслеживают одновременно и что можно узнать в текущей рабочей точке и, по мере того как информация теряет свежесть, как перейти в рабочую точку, где можно получить более свежие данные.
Когда получаем подтверждение (ack)
Каждое подтверждение предоставляет новый RTT и измерения средней скорости доставки, которая обновляет оценки RTprop и BtlBw:
Function onAck(packet)
rtt = now - packet.sendtime
update_min_filter(RTpropFilter, rtt)
delivered += packet.size
delivered_time = now
deliveryRate = (delivered - packet.delivered) / (delivered_time - packet.delivered_time)
if (deliveryRate > BtlBwFilter.currentMax || ! packet.app_limited)
update_max_filter(BtlBwFilter, deliveryRate)
if (app_limited_until > 0)
app_limited_until = app_limited_until - packet.size
Проверка if нужна из-за проблемы неопределённости, о которой говорилось в последнем параграфе: отправители могут быть ограничены приложением, то есть у приложения могут закончиться данные для заполнения сети. Это довольно типичная ситуация из-за трафика запрос/ответ. Когда есть возможность для отправки, но никакие данные не отправляются, BBR помечает соответствующие образцы пропускной способности как «ограниченные приложением», то есть app_limited (см. псевдокод send()). Этот код определяет, какие образцы включать в модель пропускной способности, так что он отражает именно сетевые ограничения, а не лимиты приложения. BtlBw является твёрдым верхним ограничением скорости доставки, так что полученная по результатам измерения скорость доставки большая, чем текущая оценка BtlBw, должна означать заниженную оценку BtlBw, независимо от того, был ли образец ограничен приложением или нет. В противном случае образцы с ограничением приложения отбрасываются. (Рисунок 1 показывает, что в регионе с ограничением приложения deliveryRate параметр BtlBw занижен). Такие проверки предотвращают заполнение фильтра BtlBw заниженными значениями, из-за которых отправка данных может замедлиться.
Когда данные отправляются
Для соотнесения скорости прибытия пакетов со скоростью вылета из узкого места BBR отслеживает каждый пакет данных. (BBR должен соответствовать rate узкого места: это значит, что отслеживание является неотъемлемой частью архитектуры и фундаментальной частью работы - поэтому pacing_rate является основным контрольным параметром. Вспомогательный параметр cwnd_gain связывает inflight с небольшим множеством BDP для обработки типичных патологий сети и получателя (см. ниже главу по задержанным и растянутым подтверждениям). Концептуально, процедура send в TCP выглядит как следующий код. (В Linux отправка данных использует эффективную процедуру массового обслуживания FQ/pacing , которая обеспечивает BBR линейную производительность одиночного соединения на мультигигабитных каналах и обрабатывает тысячи соединений с более низкой скоростью с незначительным оверхедом CPU).
Function send(packet)
bdp = BtlBwFilter.currentMax × RTpropFilter.currentMin
if (inflight >= cwnd_gain × bdp)
// wait for ack or retransmission timeout
return
if (now >= nextSendTime)
packet = nextPacketToSend()
if (! packet)
app_limited_until = inflight
return
packet.app_limited = (app_limited_until > 0)
packet.sendtime = now
packet.delivered = delivered
packet.delivered_time = delivered_time
ship(packet)
nextSendTime = now + packet.size / (pacing_gain × BtlBwFilter.currentMax)
timerCallbackAt(send, nextSendTime)
Поведение в устойчивом состоянии
Скорость и количество данных, отправляемых по BBR, зависит только от BtlBw и RTprop, так что фильтры контролируют не только оценки ограничений узкого места, но и их применение. Это создаёт нестандартный контур управления, изображённый на рисунке 2, на котором показаны RTT (синим), inflight (зелёным) и скорость доставки (красным) на протяжении 700 миллисекунд для 10-мегабитного 40-миллисекундного потока. Жирная серая линия над скоростью доставки - это состояние фильтра BtlBw max. Треугольные формы получаются от цикличного применения коэффициента pacing_gain в BBR для определения увеличения BtlBw. Коэффициент передачи в каждой части цикла показан выровненным по времени с данными, на которые он повлиял. Этот коэффициент сработал на RTT раньше, когда данные отправлялись. Это показано горизонтальными неровностями в описании последовательности событий с левой стороны.
Рисунок 2
BBR сводит к минимум задержку, потому что основная часть времени проходит с одной и той же BDP в действии. За счёт этого узкое место передвигается к отправителю, так что увеличение BtlBw становится незаметным. Следовательно, BBR периодически тратит интервал RTprop на значении pacing_gain > 1, которое увеличивает скорость отправки и объём отправленных данных без подтверждения доставки (inflight). Если BtlBw не меняется, то очередь создаётся перед узким местом, увеличивая RTT, что сохраняет неизменным показатель deliveryRate . (Очередь можно устранить, отправляя данные с компенсирующим значением pacing_gain < 1 для следующего RTprop). Если BtlBw увеличивается, то скорость deliveryRate тоже увеличивается, а новое максимальное значение фильтра немедленно увеличивает базовую скорость отслеживания (pacing_rate ). По этой причине BBR приспосабливается к новому размеру узкого места экспоненциально быстро. Рисунок 3 показывает этот эффект на 10-мегабитном 40-миллисекундном потоке, который BtlBw внезапно увеличивает до 20 Мбит/с после 20 секунд устойчивой работы (в левой части графика), затем сбрасывает до 10 Мбит/с после ещё 20 секунд устойчивой работы на 20 Мбит/с (правая часть графика).
Рисунок 3
(По сути, BBR - это простой пример управляющей системы «макс-плюс», нового подхода к системам управления, основанном на нестандартной макс-плюс алгебре . Этот подход позволяет адаптировать скорость [управляется коэффициентом передачи max ] независимо от роста очереди [управляется коэффициентом передачи average ]. В применении к нашей задаче это сводится к простому, безусловному контуру управления, где адаптация к изменениям физических ограничений автоматически осуществляется изменением фильтров, выражающих эти ограничения. Традиционная система потребовала бы создания множества контуров управления, объединённых в сложный конечный автомат, чтобы добиться такого результата).
Рисунок 4
Рисунок 4 показывает первую секунду 10-мегабитного 40-миллисекундного потока BBR. На верхнем графике отложено время и последовательность событий, а также прогресс отправителя (зелёным) и получателя (синим): объём переданных и полученных данных. Красная линия показывает показатели отправителя по технологии CUBIC при тех же условиях. Вертикальные серые линии означают моменты перехода между состояниями BBR. На нижнем графике - изменение времени двойного прохода пакетов (RTT) обоих соединений. Обратите внимание, что шкала времени для этого графика соответствует времени получения подтверждения о прибытии (ack). Поэтому может показаться, что графики будто смещены во времени, но на самом деле события внизу соответствуют тем моментам, когда система BBR узнаёт об этих событиях и реагирует.
Нижний график на рисунке 4 сравнивает BBR и CUBIC. Сначала их поведение почти одинаково, но BBR полностью опустошает образовавшуюся при запуске соединения очередь, а CUBIC не может этого сделать. У неё нет модели трассы, которая сообщила бы, сколько отправленных данных являются излишними. Поэтому CUBIC менее агрессивно наращивает передачу данных без подтверждения доставки, но этот рост продолжается до тех пор, пока буфер узкого места не переполнится и не начнёт отбрасывать пакеты, или до достижения лимита у получателя на отправленные данные без подтверждения (окно приёма TCP).
Рисунок 5 показывает поведение RTT в первые восемь секунд соединения, изображённого на предыдущем рисунке 4. Технология CUBIC (красным) заполняет весь доступный буфер, затем крутится между 70% и 100% заполнения каждые несколько секунд. После запуска соединения BBR (зелёным) работает практически без создания очереди.
Рисунок 5
Рисунок 6
Циклы изменения коэффициентов усиления ProbeBW (рисунок 2) стимулируют бóльшие потоки уступать полосу меньшим потокам, в результате чего каждый поток понимает своё честное состояние. Это происходит довольно быстро (несколько циклов ProbeBW), хотя несправедливость может сохраняться, если опоздавшие к началу передела потоки переоценивают RTprop из-за того, что начавшие ранее потоки (временно) создают очередь.
Чтобы выяснить настоящий RTProp, поток перемещается налево от линии BDP, используя состояние ProbeRTT: если оценка RTProp не обновляется (то есть путём замера меньшего RTT) в течение многих секунд, то BBR входит в состояние ProbeRTT, уменьшая количество отправляемых данных (inflight) до четырёх пакетов по крайней мере для одного двойного прохода, а затем возвращается в предыдущее состояние. Когда большие потоки входят в состояние ProbeRTT, то из очереди изымается много пакетов, так что сразу несколько потоков видят новое значение RTprop (новое минимальное RTT). Благодаря этому их оценки RTprop обнуляются одновременно, так что они все вместе входят в состояние ProbeRTT - и очередь уменьшается ещё сильнее, в результате чего ещё больше потоков видят новое значение RTprop, и так далее. Такая распределённая координация - ключевой фактор одновременно для честного распределения полосы и стабильности.
BBR синхронизирует потоки вокруг желаемого события, коим является пустая очередь в узком месте. В противоположность такому подходу, регулирование заторов по потере пакетов синхронизирует потоки вокруг нежелательных событий, таких как периодический рост очереди и переполнение буфера, что увеличивает задержку и потерю пакетов.
Рисунок 7
Рисунок 7 показывает относительное улучшение BBR по сравнению с CUBIC; на врезке - интегральные функции распределения (cumulative distribution functions, CDF) для пропускной способности. Замеры произведены с помощью службы активного зондирования, которая открывает постоянные соединения BBR и CUBIC к удалённым дата-центрам, затем каждую минуту передаёт по 8 МБ данных. Зонды исследуют много маршрутов B4 между Северной Америкой, Европой и Азией.
Огромное улучшение - прямое следствие того, что BBR не использует потерю пакетов как индикатор затора. Для достижения полной пропускной способности существующим методам регулирования заторов по потере пакетов нужно, чтобы уровень потерь был меньше, чем обратный квадрат BDP (например, менее одной потери на 30 миллионов пакетов для соединения 10 Гбит/с и 100 мс). На рисунке 8 сравнивается измеренная полезная пропускная способность на различных уровнях потерь пакетов. В алгоритме CUBIC допуск на потерю пакетов является структурным свойством алгоритма, а в BBR это параметр конфигурации. По мере того, как уровень потерь в BBR приближается к максимальному коэффициенту усиления ProbeBW, вероятность измерения скорости доставки реального BtlBw резко падает, что приводит к недооценке со стороны фильтра max.
Рисунок 8
Рисунок 8 сравнивает полезную пропускную способность BBR и CUBIC в 60-секундном потоке на соединении 100 Мбит/c и 100 мс со случайными потерями от 0,001% до 50%. Пропускная способность CUBIC уменьшается в 10 раз при потерях 0,1% и полностью глохнет при более 1%. Максимальной пропускной способностью считается доля полосы за минусом потерь пакетов (). BBR держится на этом уровне до уровня потерь 5% и близко к нему до 15%.
Рисунок 9 показывает медианное улучшение RTT в сравнении BBR и CUBIC по статистике более 200 млн просмотров видео на YouTube, измеренных на пяти континентах в течение недели. Более половины из всех 7 млрд мобильных соединений в мире подключаются по 2.5G на скорости от 8 до 114 Кбит/с , испытывая хорошо задокументированные проблемы из-за того, что методы регулирования заторов по потере пакетов склонны переполнять буферы . Узкое место в этих системах обычно находится между SGSN (обслуживающий узел поддержки GPRS) и мобильным устройством. Программное обеспечение SGSN работает а стандартной платформе ПК с обильным количеством ОЗУ, где часто имеются мегабайты буфера между интернетом и мобильным устройством. Рисунок 10 сравнивает (эмулированную) задержку SGSN между интернетом и мобильным устройством для BBR и CUBIC. Горизонтальные линии отмечают одни из наиболее серьёзных последствий: TCP адаптируется к длительным задержкам RTT за исключением пакета SYN, инициирующего соединение, у которого фиксированный таймаут, в зависимости от операционной системы. Когда мобильное устройство получает большой массив данных (например, от автоматического обновления программного обеспечения) через SGSN с большим буфером, устройство не может установить никакое соединение в интернете, пока очередь не освободится (подтверждающий пакет SYN ACK задерживается на большее время, чем фиксированный таймаут SYN).
Рисунок 9
Рисунок 10 показывает медианные изменения RTT в устойчивом состоянии соединения и зависимость от размера буфера на соединении 128 Кбит/с и 40 мс с восемью потоками BBR (зелёным) или CUBIC (красным). BBR удерживает очередь у минимальных значений, независимо от размера буфера узкого места и количества активных потоков. Потоки CUBIC всегда заполняют буфер, так что задержка увеличивается линейно с размером буфера.
Рисунок 10
Технология BBR используется на бэкбоне Google B4, на порядки улучшая пропускную способность по сравнению с CUBIC. Она также разворачивается на веб-серверах Google и YouTube, в значительной степени уменьшая задержку на всех пяти континентах, протестированных к настоящему времени, а особенно сильно в развивающихся странах. Технология BBR работает исключительно на стороне отправителя и не требует изменений в протоколе, у получателя или в сети, что позволяет развёртывать её постепенно. Она зависит только от RTT и уведомлений о доставке пакетов, так что её можно применять в большинстве транспортных протоколов интернета.
Выражение признательности
Авторы благодарны Лену Клейнроку за указание, как нужно правильно регулировать заторы. Мы в долгу перед Ларри Бракмо (Larry Brakmo) за новаторскую работу над системами регулирования заторов Vegas и New Vegas, которые предвосхитили многие элементы BBR, а также за его советы и руководство на начальном этапе разработки BBR. Мы также хотели бы поблагодарить Эрика Думазета (Eric Dumazet), Нандиту Дуккипати (Nandita Dukkipati), Яну Айенгар (Jana Iyengar), Яна Светта (Ian Swett), Фитца Ноулана (M. Fitz Nowlan), Дэвида Уэзерала (David Wetherall), Леонидаса Контотанассиса (Leonidas Kontothanassis), Амина Вахдата (Amin Vahdat) и группы разработки Google BwE и инфраструктуры YouTube за их неоценимую помощь и поддержку.
Коэффициент усиления pacing_gain управляет, как быстро отправляются пакеты относительно BtlBw, и это ключ к интеллектуальной функции BBR. При pacing_gain больше единицы увеличивается inflight и уменьшается промежуток между поступлениями пакетов, что передвигает соединение в правую часть на рисунке 1. При pacing_gain меньше единицы происходит обратный эффект, соединение передвигается влево.
BBR использует pacing_gain для реализации простой машины последовательного зондирования состояний, которая чередуется между тестированием на бóльшую полосу и тестированием на меньшее время двойного прохода пакета. (Необязательно тестировать на меньшую полосу, потому что она обрабатывается автоматически фильтром BtlBw msx: новые измерения отражают падение, так что BtlBw скорректирует себя сразу, как только последние старые изменения уберутся из фильтра по таймауту. Фильтр RTprop min таким же образом обрабатывает увеличение пути доставки).
Если увеличивается пропускная способность бутылочного горлышка, BBR должен отправлять данные быстрее, чтобы обнаружить это. Точно так же, если меняется реальное время двойного прохода пакета, это меняет BDP, и поэтому BDP должен отправлять данные медленнее, чтобы удержать inflight ниже BDP для измерения нового RTprop. Поэтому единственный способ обнаружить эти изменения - проведение экспериментов, отправляя быстрее для проверки увеличения BtlBw или отправляя медленнее для проверки уменьшения RTprop. Частота, масштаб, продолжительность и структура этих экспериментов различаются в зависимости от того, что уже известно (запуск соединения или стабильное состояние) и от поведения приложения, которое отправляет данные (прерывистое или постоянное).
Устойчивое состояние
Потоки BBR тратят бóльшую часть своего времени в состоянии ProbeBW, зондируя полосу с помощью метода под названием gain cycling , что помогает потокам BBR достичь высокой пропускной способности, низкой задержки в очереди и сходимости в честном разделе полосы. Используя gain cycling , BBR циклично пробует ряд значений для коэффициента усиления pacing_gain . Используется восемь фаз цикла со следующими значениями: 5/4, 3/4, 1, 1, 1, 1, 1, 1. Каждая фаза обычно идёт в течение прогнозируемого RTprop. Такой дизайн позволяет циклу коэффициента сначала зондировать канал на бóльшую пропускную способность со значением pacing_gain больше 1.0, а затем рассредотачивать любую образовавшуюся очередь с помощью pacing_gain на такую же величину меньше 1.0, а затем двигаться на крейсерской скорости с короткой очередью коэффициентов ровно 1.0. Средний коэффицент усиления для всех фаз равняется 1.0, потому что ProbeBW стремится к среднему значению, чтобы уравняться с доступной полосой пропускания и, следовательно, сохранить высокую степень использования полосы, не увеличивая при этом очередь. Обратите внимание, что хотя циклы изменений коэффицента изменяют pacing_gain , но значение cwnd_gain неизменно остаётся равным двум, поскольку задержанные и растянутые пакеты подтверждения могут появиться в любой момент (см. главу о задержанных и растянутых пакетах ack).
Более того, для улучшения смешивания потоков и справедливого разделения полосы, и для уменьшения очередей, когда многочисленные потоки BBR совместно используют узкое место, BBR случайным образом изменяет фазы цикла ProbeBW, случайно выбирая первую фазу среди всех значений, кроме 3/4. Почему цикл не начинается с 3/4? Главная задача этого значения коэффициента - рассредоточить любую очередь, которая может образоваться во время применения коэффициента 5/4, когда канал уже полный. Когда процесс выходит из состояния Drain или ProbeRTT и входит в ProbeBW, то очередь отсутствует, так что коэффициент 3/4 не выполняет свою задачу. Применение 3/4 в таком контексте имеет только негативный эффект: заполнение канала в этой фазе будет 3/4, а не 1. Таким образом, начало цикла с 3/4 имеет только негативный эффект, но не имеет положительного, а поскольку вход в состояние ProbeBW происходит на старте любого соединения достаточно долго, то BBR использует эту маленькую оптимизацию.
Потоки BBR действуют сообща, чтобы периодически опустошать очередь в узком месте при помощи состояния, которое называется ProbeRTT. В любом состоянии кроме самого ProbeRTT, если оценка RTProp не обновлялась (например, посредством замера меньшего RTT) более 10 секунд, то BBR входит в состояние ProbeRTT и уменьшает cwnd до очень маленького значения (четыре пакета). Сохраняя такое минимальное количество пакетов «в полёте» по крайней мере 200 мс и на протяжении одного времени двойного прохода пакета, BBR выходит из состояния ProbeRTT и входит или в Startup, или в ProbeBW, в зависимости от оценки, заполнен ли уже канал.
BBR создан, чтобы работать бóльшую часть времени (около 98%) в состоянии ProbeBW, а остальное время - в ProbeRTT, основываясь на наборе компромиссов. Состояние ProbeRTT продолжается достаточно долго (по крайней мере, 200 мс), чтобы позволить потокам с разными RTT иметь параллельные состояния ProbeRTT, но в то же время оно продолжается достаточно короткий промежуток времени, чтобы ограничить снижение производительности примерно двумя процентами (200 мс / 10 секунд). Окно фильтра RTprop (10 секунд) достаточно маленькое, чтобы быстро подстроиться под изменение уровня трафика или изменение маршрута, но при этом достаточно большое для интерактивных приложений. Такие приложения (например, веб-страницы, вызовы удалённых процедур, фрагменты видео) часто демонстрируют естественные периоды молчания или малой активности в раках этого окна, где скорость потока достаточно низкая или достаточно продолжительная, чтобы рассредоточить очередь в узком месте. Затем фильтр RTprop оппортунистически подбирает эти измерения RTprop, а RTProp обновляется без необходимости задействовать ProbeRTT. Таким образом, потокам обычно требуется всего лишь жертвовать 2% полосы, если многочисленные потоки обильно заполняют канал на протяжении целого окна RTProp.
Поведение при запуске
Когда запускается поток BBR, он осуществляет свой первый (и самый быстрый) последовательный процесс зондирования/опустошения очереди. Сетевая пропускная способность изменяется в диапазоне 10 12 - от нескольких бит до 100 гигабит в секунду. Чтобы выяснить значение BtlBw при таком гигантском изменении диапазона, BBR осуществляет двоичный поиск в пространстве скорости. Он очень быстро находит BtlBw ( двойных проходов пакетов), но за счёт создания очереди в 2BDP на последнем этапе поиска. Поиск выполняется в состоянии Startup в BBR, а опустошение создавшейся очереди - в состоянии Drain.
Сначала Startup экспоненциально увеличивает скорость отправки данных, удваивая её на каждом раунде. Чтобы добиться такого быстрого зондирования наиболее спокойным образом, при запуске значения коэффициентов усиления pacing_gain и cwnd_gain установлены на , в минимальное значение, которое позволяет удваивать скорость отправки данных на каждом раунде. Как только канал заполняется, коэффициент cwnd_gain ограничивает размер очереди значением .
В состоянии запуска соединения BBR оценивает, заполнен ли канал, с помощью поиска плато в оценке BtlBw. Если обнаруживается, что прошли несколько (три) раунда, где попытки удвоить скорость доставки реально не даёт большой прибавки скорости (менее 25%), то он считает, что достиг BtlBw, так что выходит из состояния Startup и входит в состояние Drain. BBR ждёт три раунда, чтобы получить убедительные доказательства, что наблюдаемое отправителем плато скорости доставки не является временным эффектом под влиянием окна приёма. Ожидание трёх раундов даёт достаточно времени для автоматической настройки на стороне получателя, чтобы раскрыть окно приёма и чтобы отправитель по BBR обнаружил необходимость увеличения BtlBw: в первом раунде алгоритм автоматической настройки окна приёма увеличивает окно приёма; во втором раунде отправитель заполняет увеличившееся окно приёма; в третьем раунде отправитель получает образцы с увеличенной скоростью доставки. Такой предел в три раунда доказал себя по результатам внедрения на YouTube.
В состоянии Drain алгоритм BBR стремится быстро опустошить очередь, которая образовалась в состоянии запуска соединения, перейдя в режим pacing_gain с обратными значениями, чем те, которые использовались в состоянии Startup. Когда количество пакетов в полёте соответствует оценке BDP, это означает, что BBR оценивает очередь как полностью опустошённую, но канал по-прежнему заполнен. Тогда BBR выходит из состояния Drain и входит в ProbeBW.
Заметьте, что запуск соединения BBR и медленный старт CUBIC оба изучают пропускную способность узкого места экспоненциально, удваивая скорость отправки на каждом раунде. Однако они кардинально отличаются. Во-первых, BBR более надёжно определяет доступную пропускную способность, поскольку он не прекращает поиск в случае потери пакета или (как Hystart у CUBIC ) увеличения задержки. Во-вторых, BBR плавно наращивает скорость отправки, в то время как у CUBIC на каждом раунде (даже с pacing) происходит всплеск пакетов, а потом период тишины. Рисунок 4 показывает количество пакетов в полёте и наблюдаетмое время RTT для каждого сообщения о подтверждении у BBR и CUBIC.
Реагирование на переходные ситуации
Сетевой путь и проход трафика по нему могут испытывать внезапные драматические изменения. Чтобы плавно и надёжно адаптироваться к ним, а также уменьшить потери пакетов в этих ситуациях, BBR использует ряд стратегий, чтобы реализовать свою базовую модель. Во-первых, BBR расценивает как цель, к которой текущий cwnd осторожно приближается снизу, увеличивая cwnd каждый раз не более чем на количество данных, для которых пришли подтверждения доставки. Во-вторых, при таймауте повторной передачи, который означает, что отправитель считает потерянными все пакеты в полёте, BBR консервативно снижает cwnd до одного пакета и отправляет единственный пакет (точно как алгоритмы регулирования заторов по потере пакетов, такие как CUBIC). В конце концов, когда отправитель замечает потерю пакета, но в полёте всё ещё есть пакеты, на первом этапе процесса по восстановлению потерь BBR временно снижает скорость отправки до уровня текущей скорости доставки; на втором и последующих раундах восстановления потерь он проверяет, что скорость отправки никогда не превышает текущую скорость доставки более чем в два раза. Это значительно снижает потери в переходных ситуациях, когда BBR сталкивается с ограничителями скорости или конкурирует с другими потоками в буфере, сравнимого размером с BDP.
Please enable Javascript to use the unit converter
How many cfm in 1 cubic metre/minute?
The answer is 35.314666212661.
We assume you are converting between cubic foot/minute
and cubic metre/minute
.
You can view more details on each measurement unit:
cfm or
cubic metre/minute
The SI derived unit for volume flow rate
is the cubic meter/second.
1 cubic meter/second is equal to 2118.8799727597 cfm, or 60 cubic metre/minute.
Note that rounding errors may occur, so always check the results.
Use this page to learn how to convert between cubic feet/minute and cubic meters/minute.
Type in your own numbers in the form to convert the units!
1 cfm to cubic metre/minute = 0.02832 cubic metre/minute
10 cfm to cubic metre/minute = 0.28317 cubic metre/minute
20 cfm to cubic metre/minute = 0.56634 cubic metre/minute
30 cfm to cubic metre/minute = 0.84951 cubic metre/minute
40 cfm to cubic metre/minute = 1.13267 cubic metre/minute
50 cfm to cubic metre/minute = 1.41584 cubic metre/minute
100 cfm to cubic metre/minute = 2.83168 cubic metre/minute
200 cfm to cubic metre/minute = 5.66337 cubic metre/minute
Cubic feet per minute (CFM) is a measure used in Industrial hygiene and ventilation engineering. It describes the rate of flow of a gas or air volume into or out of a space.
A standard measurement of airflow that indicates how many cubic feet of air pass by a stationary point in one minute. The higher the number, the more air is being forced through the system. The volumetric flow rate of a liquid or gas in cubic feet per minute. 1 CFM equals approximately 0.47 liter per second.
сайт provides an online conversion calculator for all types of measurement units. You can find metric conversion tables for SI units, as well as English units, currency, and other data. Type in unit symbols, abbreviations, or full names for units of length, area, mass, pressure, and other types. Examples include mm, inch, 100 kg, US fluid ounce, 6"3", 10 stone 4, cubic cm, metres squared, grams, moles, feet per second, and many more!
В этой статье мы изложим некоторые понятия, которыми нужно пользоваться при выборе корпусного вентилятора и расскажем о характерных для разных видов вентиляторов особенностях. Кроме того, мы проведем тестирование 120 мм вентилятора akasa Amber AK-183-L2B, который уже больше года служит в качестве активного элемента системы процессорного охлаждения Thermaltake Sonic Tower, используемой при тестировании процессоров и видеокарт. И надо отметить, что он вполне заслужил право стать первым героем в серии обзоров посвященных вентиляторам на нашем ресурсе.
Вопросами, на которые мы постараемся ответить, будут...
Какие требования можно предъявить к корпусному вентилятору?
В чем заключаются основные отличия корпусных вентиляторов?
1.Габаритные размеры – размер крыльчатки.
Для создания внутренней вентиляции в корпусе в большинстве случаев применяются вентиляторы с типоразмером равным 80 мм, 92 мм или 120 мм, так как для их установки в корпусе изначально предусматриваются монтажные отверстия. Совершенно понятно, что чем больше размер крыльчатки у вентилятора, тем выше у него способность нагнетать воздушный поток. Поэтому вентилятору с меньшим размером для достижения показателей эффективности больших моделей придется вращаться с более высокой скоростью и, соответственно, издавать значительно больше шума. Собственно по этой причине популярностью пользуются именно большие 120 мм вентиляторы.
Для наглядности этих свойств, можно сравнить характеристики моделей вентиляторов одной серии компании Xinruilian Science & Technology Co. , имеющие разные размеры:
Размер, мм |
|||
Скорость об/мин |
|||
Воздушный поток, CFM |
|||
Уровень шума, дБ |
|||
Давление, мм H 2 0 |
Судя по приведенным характеристикам моделей можно сделать вывод, что при одинаковой скорости вращения 92 мм вентилятор будет в 1,65 раз более производительным, чем 80 мм, а 120 мм вентилятор будет в два раза эффективней 92 мм модели, с учетом того, что все вентиляторы обладают одним типом крыльчатки.
Помимо разных диаметров крыльчатки, также не менее важным является размер профиля или глубины вентилятора. «Классическим» для обычных корпусов есть 25 мм профиль. С меньшим профилем вентиляторы называют низкопрофильными, а с большим – высокопрофильные. От величины профиля напрямую зависит сила воздушного потока, которая характеризуется в спецификации величиной максимального давления.
Для примера сравним характеристики двух 120 мм моделей – с обычным профилем и высоким профилем, работающих на одной скорости вращения.
Размер, мм |
||
Скорость об/мин |
||
Воздушный поток, CFM |
||
Уровень шума, дБ |
||
Давление, мм H20 |
Из таблицы видно, что высокопрофильный вентилятор отличается лишь лучшим показателем максимального давления воздушного потока. В обычных компьютерных системах нет нужды в создании избыточного давления, поэтому эти вентиляторы не находят в них применения. В большинстве случаев высокопрофильные вентиляторы используются в серверах, кроме того они имеют повышенную скорость вращения и как следствие достаточно большой рабочий шум.
2.Тип подшипника.
В вентиляторах используют три основных типа подшипника: скольжения, комбинированный вариант скольжения и качения, и состоящий из двух подшипников качения. Кроме этих типов подшипника, заметно реже, встречаются гидродинамические виды, которые специально разрабатываются отдельно некоторыми производителями.
Чаще всего, определить тип подшипника можно по наличию в названии модели вентилятора следующих индексов, хотя всегда желательно сверяться с официальной спецификацией:
S
(sleeve
)
– подшипник скольжения, который по сути является втулкой;
С (combo
)
- один шарикоподшипник и короткая втулка;
B (ball)
или 2B (2 ball)
– два шарикоподшипника.
Самым простым и дешевым, но, к сожалению, не особо долговечным является подшипник скольжения. Этот подшипник имеет вид небольшой медной втулки, внутри которой, вращаясь, скользит вал (стержень) крыльчатки. Новый вентилятор со смазанным подшипником скольжения может быть совершенно бесшумным, но по истечению времени это свойство может и потеряется. При отсутствии должного уровня смазки довольно быстро происходит «выработка» втулки, из-за чего вентилятор начинает шуметь. Кроме того, при отсутствии смазки, работая в зоне с повышенной температурой, вентилятор может совсем заклинить. Особенно наглядно этот факт демонстрируют случаи с недорогими китайскими блоками питания, в которых не редко бывали случаи остановки вентилятора на подшипнике скольжения, обеспечивающего охлаждение силовых полупроводниковых элементов. В результате чего блок питания выходил из строя.
Комбинированный вариант подшипника имеет сравнительно больший ресурс работы подшипника.
Подшипник, состоящий из двух шарикоподшипников, является наиболее дорогим, но в тоже время, более долговечным вариантом. Такой тип подшипника может свободно работать в зоне с повышенной температурой. Но в тоже время часто среди таких вентиляторов можно встретить экземпляры, издающие достаточно громкий и неприятный шум. Подобная картина особенно характерна для дешевых вентиляторов, потому как от качества изготовления миниатюрного подшипника напрямую зависят шумовые характеристики всей конструкции. Поэтому, если вы выбираете продукт на шарикоподшипниках, ни в коем случае не гонитесь за его дешевизной, потому как даже более дорогие модели редко бывают тихими.
3. Класс двигателя.
Все корпусные вентиляторы работают на четырехполюсных двигателях постоянного тока. По скорости все они классифицированы на три категории: до 2000 об/мин тихоходные, от 2000 до 3000об/мин средние и свыше 3000 об/мин быстроходные. Узнать класс двигателя вентилятора зачастую можно по индексу в его наименовании, которое часто указывается на наклейке:
L (low
)
– тихоходный (до 2000
об/мин);
M
(middle
)
– средний (от 2000 до 3000
об/мин);
H
(high
)
– быстроходный (свыше 3000
об/мин).
Что характеризуют данные, приведенные в спецификации производителей?
Скорость вращения вентилятора измеряется в количестве оборотов за одну минуту (RPM - rotations per minute). Так как сама скорость вентилятора может меняется почти прямо пропорционально напряжению питания, то приведенная в спецификации величина соответствует номинальному напряжению его питания. Чем выше скорость вращения, тем более эффективен вентилятор, но и, обычно, более шумный.
Воздушный поток может указываться в CFM (cubic feet per minute, CFM) - кубический фут в минуту или в кубических метрах в час (м 3 /ч). При этом 1 CFM ≈ 1,7 м 3 /ч. Данная величина отображает количество «перекачанного» воздуха за определенный промежуток времени при условии полного отсутствия сопротивления воздушному потоку, то есть при равном воздушном давлении с обеих сторон вентилятора. Конечно, чем больше эта величина, тем лучше.
Статическое давление воздушного потока вентилятора обычно приводится в мм водяного столба и характеризует силу воздушного потока, которую может создавать вентилятор.
Напомним, что давление вычисляется по формуле P=F/S. То есть давление есть отношением силы воздушного потока к площади на которую она действует. В спецификации указывается максимальное значение воздушного потока, которую создает вентилятор, когда он из-за сопротивления не может создавать воздушный поток.
Всю характеристику вентилятора можно увидеть на графике «Кривая производительности».
Кривая производительности представляет зависимость воздушного потока от давления. Самая верхняя точка кривой, находящаяся на оси, является как раз ни чем иным, как максимальным давлением, которое приводится в спецификации. Нижняя точка кривой, лежащая на другой оси, соответствует максимальному воздушному потоку вентилятора, когда ему не приходиться создавать давление. В реальных условиях, а именно в корпусе, воздушный поток должен преодолевать некоторое сопротивление. Каждый корпус индивидуально имеет свою степень сопротивления. Сопротивление системы будет выражаться наклонной на графике, а точка пересечения прямой и кривой является ни чем иным как рабочей точкой вентилятора в нашей условной системе.
Ресурс вентилятора измеряется количеством тыс. часов, в течение которого вентилятор должен работать и обеспечивать заявленные характеристики. Автору статьи до конца не известно, в каких рабочих условиях достигаются приводимые величины, так как от условий работу напрямую зависит срок службы. Подразумевается, что вентилятор способен без потери своих шумовых качеств отработать указанное число часов. Ресурс во многом зависит от типа и качества подшипника. Для подшипников скольжения обычно указывают 30 000 часов, для комбинированного – 45 000 часов, а для двойного шарикоподшипника приводятся значения в 60 000 часов и выше.
В большинстве случаев вентилятор на подшипнике скольжения довольно тихо может работать около года, хотя производители заявляют цифру в 30 тыс. Потому не следует относиться к этим числам предвзято - они достаточно относительны. И если покопаться, то окажется, что производитель подразумевал еще и периодическое обслуживание вентиляторов, т.е. смазку, которую обычные пользователи редко производят.
Теперь снова вернемся к герою нашего обзора вентилятору akasa AK-183-L2B и посмотрим на его спецификацию:
akasa AK-183-L2B |
|
Размер, мм |
|
Скорость вращения, об/мин |
|
Воздушный поток, CFM |
|
Давление, мм H20 |
|
Ресурс, ч |
|
Тип подшипника |
два качения |
3-контактный |
|
Уровень шума, дБ |
|
Напряжение питания, В |
|
Сайт производителя |
|
Средняя цена |
Вентилятор akasa AK-183-L2B упакован в прозрачную пластиковую упаковку. В упаковке с обратной стороны находится картонный лист синего цвета, подчеркивающий прозрачный корпус и полупрозрачную янтарно-желтую крыльчатку вентилятора. В общем, все оформлено в привычном фирменном сине-желтом цвете компании Akasa Group.
С обратной стороны картонной вкладки на пяти разных языках приведена спецификация.
Кроме вентилятора в самом низу упаковки вложена небольшая картонная коробка черного цвета с надписью в переводе звучащей как «3-4 контактный переходник».
Поэтому совершенно не удивительно, что в коробке находился таки переходник, позволяющий подключать вентилятор от разъемов периферийных устройств, и кроме того, дополнительно имеющий 3-контактный разъем для контроля скорости вращения вентилятора. Также в небольшой черной коробке находилось четыре винта для установки вентилятора в корпус.
Корпус вентилятора akasa AK-183-L2B сделан из белого прозрачного пластика, а его крыльчатка - из янтарно-желтого полупрозрачного пластика. Собственно, если рассматривать весь ассортимент продукции компании akasa, то в нем редко попадаются какие-то простые и стандартные решения, потому как компания занимается распространением товаров по большей части рассчитанных именно для моддинга. Но это совершенно не значит, что если вы не относите себя к касте моддеров и привыкли оценивать товар только из практических соображений, то этот вентилятор и остальной похожий товар вам не подходит. На самом деле, при производстве продукции для так называемых непростых пользователей, моддеров или оверлокеров, всегда подразумевается повышенное внимание в первую очередь к качеству изготовления и несколько более высоким его свойствам. Поэтому, совершенно не удивительно, что почти всегда потребительские качества подобной продукции оказываются выше, чем у простых товаров.
Внешне вентилятор, безусловно, выделяется в первую очередь красивым сочетанием желтого и белого цвета, и кажется, что подобный вентилятор просто обязан иметь подсветку, но на самом деле ее нет. С точки зрения аэродинамики, никаких новшеств или ноу-хау в вентиляторе не реализовано – простая семилопастная крыльчатка.
Вентилятор akasa AK-183-L2B относится к тихоходным моделям, его номинальная скорость вращения составляет 1400 об/мин при этом максимальный поток воздуха может достигать величины в 44,8 CFM, а статическое давление 1,1 мм водяного столба. Характеристики ни сверхвысокие и достаточно обычные, но это не удивительно, так как для корпусного вентилятора домашней системы в первую очередь ставятся повышенные требования к шуму.
И в этом плане по спецификации указывается достаточно низкая величина шума равная 18 дБ. Надо отметить, что вентилятор akasa AK-183-L2B основан на двух шарикоподшипниках, а его ресурс по данным производителя составляет 80 000 часов. Привычным значением для шарикоподшипников являются значения в 60 000 часов, поэтому несколько увеличенное значение дает повод надеяться на более качественный подход к их изготовлению, потому как мы уже отмечали, именно качество изготовления шарикоподшипника определяет его шумовые характеристики.
Вентилятор питается от 3-контактного разъема питания, не поддерживающий широтно-импульсные источники питания.
Тестирование
Практическая часть теста состоит из двух этапов тестирования создаваемого воздушного потока вентилятора на номинальных оборотах, а также оценки его громкости на слух.
Тест №1
В первом тесте вентилятор будет выполнять роль активного элемента кулера Thermalright SI-128. Тестирование производится в открытом корпусе, и основным контролируемым параметром является температура нагрева разогнанного до частоты 2,8 ГГц процессора Intel Core 2 Duo E6300 и температура системной платы.
Тест №2
Во втором тесте вентилятор будет применяться по прямому назначению в качестве корпусного вентилятора, установленного на задней панели и работающего на выдув. Во время теста корпус будет закрыт и никаких других включенных вентиляторов в нем не будет. Основным контролируемым параметром также будет температура нагрева процессора Intel Core 2 Duo E6300, но теперь без разгона, на который установлена пассивная система охлаждения Thermaltake Sonic Tower (CL-P0071) и температура системной платы. Результат теста фиксируется после 10 минутного «прогона» стресс-теста процессора в приложении Everest.
Тестовая конфигурация платформы с процессором Intel состоит из следующих компонентов:
Материнская плата |
Gigabyte GA-965P-DS4 (Intel P965 Express) |
Процессор |
Intel Core 2 Duo E6300 (LGA775, 1,86 ГГц, L2 2 Мб) @2,8 ГГц |
Оперативная память |
2 х DDR2-800 1024 Мб Apacer PC6400 |
Видеокарта |
EVGA GeForce 8600GTS 256 Mб DDR3 PCI-E |
Жесткий диск |
Samsung HD080HJ, 80 Гб, SATA-300 |
Оптический привод |
ASUS DRW-1814BLT SATA |
Блок питания |
Chieftec CFT-500-A12S 500W, 120 мм вентилятор |
CODEGEN M603 MidiTower |
Вентилятор akasa AK-183-L2B демонстрирует хорошую производительность на равне с остальными конкурентами. Достаточно низкий заявленный уровень шума в 18 дБ мы можем подтвердить лишь своим субъективным мнением. Указанная величина действительно вполне соответствует реальному уровню шуму - на максимальных оборотах он издает небольшой гул.
Выводы.
Вентилятор akasa AK-183-L2B не является исключительно моддинговым красивым украшением, как может сразу показаться покупателю. Он может создать достаточно большой воздушный поток, а, самое главное, издает при этом достаточно низкий уровень шума. Если же учитывать его приемлемую стоимость как для качественной модели шарикоподшипникового вентилятора, то в этой категории товаров по соотношению цена/потребительские качества он будет одним из лучших. Повторимся, что в нашей тестовой лаборатории вентилятор akasa AK-183-L2B успел поработать уже больше года, и его шумовые качества за это время практически не изменились.
Достоинства:
К недостаткам отнесем:
Выражаем благодарность фирме ООО ПФ Сервис (г. Днепропетровск) за предоставленное для тестирования оборудование.
Статья прочитана 4669 раз(а)
Подписаться на наши каналы | |||||