Джон Дикс

Для поддержки полумиллиарда пользователей LinkedIn по всему миру требуются немалые вычислительные мощности, особенно если учесть, что каждому из них нужны персональные настройки с выдачей веб-страницы, на которой присутствуют только его контакты. Сегодня социальную сеть обслуживают свыше 100 тыс. серверов, распределенных между несколькими ЦОДами. Чтобы поближе познакомиться с тем, как LinkedIn справляется со всем этим, главный редактор журнала Network World Джон Дикс побеседовал с вице-президентом LinkedIn по производственным операциям и ИТ Сону Навьяром и старшим директором компании по проектированию инфраструктуры Саидом Али Каном.

Давайте начнем с общей картины того, что имеется в ваших ЦОДах, развернутых в разных странах.

Навьяр: Сайт LinkedIn.com в глобальном масштабе обслуживается тремя ЦОДами, которые расположены в США: в Ричардсоне (штат Техас), в Эшберне (Вирджиния) и в только что открытом ЦОДе в штате Орегон. Еще у нас есть небольшой ЦОД в Сингапуре, запущенный в эксплуатацию в начале нынешнего года. Главное его предназначение – улучшение обслуживания наших пользователей в Юго-Восточной Азии. Все четыре ЦОДа подключены к магистрали MPLS и к 13 глобальным точкам присутствия.

Они построены на базе единой архитектуры или же их архитектура различается, в силу того что все они создавались в разное время?

Сону Навьяр, вице-президент LinkedIn по производственным операциям и ИТ

Навьяр: Архитектура их носит смешанный характер. Прежде чем приступить к строительству своего первого ЦОДа в Эшберне, мы использовали услуги колокации. В дальнейшем технология год от года совершенствовалась, и ЦОД в Орегоне функционирует уже совсем по-другому.

Кан: Переход к оптовой модели начался с самого первого ЦОДа в Вирджинии. Вместо того чтобы обращаться к розничным поставщикам вычислительных мощностей наподобие Equinix, мы просто арендовали для ЦОДа пространство – большое пустое сооружение – и начали оборудовать его внутри самостоятельно, размещая там средства энергоснабжения, кабели, стойки и все прочее. Затем еще один ЦОД был построен в Техасе – развитие шло очень быстрыми темпами. Когда подошел черед строительства в Орегоне, мы проанализировали накопленный опыт и задумались, как будут выглядеть наши ЦОДы в будущем. Именно тогда и произошел переход к модели гипермасштабирования. Двигаясь дальше, мы намерены модифицировать все прочие ЦОДы в соответствии с новой моделью.

Значит, вы не собираетесь, подобно некоторым веб-гигантам, создавать свои собственные серверы?

Кан: Нет. Мы используем отдельные серверы, монтируемые в стойке. И поддерживаем тесные отношения с теми поставщиками OEM-оборудования, которые предлагают продукты, отвечающие нашим требованиям к производительности и т. д. Наша компания была одним из первых крупных пользователей систем Cisco UCS, но в последнее время мы больше склоняемся к стандартному оборудованию Supermicro.

А ваши собственные бизнес-потребности удовлетворяются тоже в этих ЦОДах?

Навьяр: У нас практикуется гибридный подход. Для хранения корпоративных ресурсов – службы персонала, финансовой службы, отделов разработки, предпродажной обработки и пр. – есть небольшой ЦОД в Санта-Кларе. Но после завершения строительства в Орегоне мы стали использовать зоны безопасности, позволяющие обслуживать корпоративные нужды в любом из имеющихся ЦОДов.

Как выглядит клиентское приложение LinkedIn?

Навьяр: Наше приложение имеет сложную структуру, и в формировании страницы пользователя при его подключении к LinkedIn.com принимают участие все ресурсы ЦОДа. Понятно, что контакты и связи у всех уникальны, поэтому страница настраивается в соответствии с индивидуальными особенностями, и в наших ЦОДах циркулируют большие объемы внутреннего трафика, генерирующего каждую из страниц. Для этого требуется много вычислений. На каждый байт, поступающий в нашу сеть, приходится в сотни раз больше байтов внутреннего трафика.

Это впечатляет...

Навьяр: В нашем приложении все взаимосвязано. Естественно, некоторые части сайта разделены. Например, модуль Recruiter имеет другой интерфейс. Но для типичного потребителя в LinkedIn.com все взаимосвязано.

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

Каждый из ваших ЦОДов поддерживает одни и те же функции или же задачи распределены между ними?

Навьяр: Трафик может обслуживаться в любом месте. Если в каком-то ЦОДе происходит сбой, мы просто перенаправляем трафик на другую площадку. Между всеми ЦОДами осуществляется в реальном времени репликация по магистрали MPLS с пропускной способностью 100 Гбит/с. ЦОДы обслуживают одинаковые запросы – таким образом повышается уровень готовности. Если один из сайтов отключается (из-за ошибки в программе, сетевых проблем, сбоев питания и даже неправильно внесенных изменений), мы можем легко восстановить работоспособность в течение пяти минут. Все компоненты взаимодействуют друг с другом, обслуживая LinkedIn.com.

Пользователи обслуживаются по географическим регионам?

Саид Али Кан, старший директор LinkedIn по проектированию инфраструктуры

Кан: Да. Мы активно используем возможности Anycast, переходя к нужному IP-адресу кратчайшим путем. Таким образом наши пользователи соединяются с ближайшей точкой присутствия.

Навьяр: Мы пытаемся понять, как осуществлять маршрутизацию запросов из той или иной части страны, и переадресовываем их на ближайшую точку присутствия. Наши точки присутствия представляют собой небольшие ЦОДы, где размещено главным образом сетевое оборудование и прокси-серверы, выступающие в роли оконечных узлов для запросов с подключением по протоколу TCP.

Кан: Положение точки присутствия выбирается с учетом пользовательского контекста. Мы знаем, из каких географических областей приходят запросы. Для упреждающего анализа мы используем модель, в которой применяем науку о данных. Она показывает, к примеру, что при выборе точки присутствия в Австралии время загрузки страницы сокращается на такой-то процент. С учетом полученной информации мы строим точку присутствия в указанной области и связываем ее с нашими ЦОДами. Запросы на загрузку страниц сначала обрабатываются в точке присутствия, а затем уже пересылаются в основные ЦОДы. Наличие точек присутствия помогает загружать страницы быстрее. А размещение точки присутствия в Азии помогло нам улучшить загрузку страниц на 25%.

Навьяр: Мы постоянно отслеживаем производительность сайта по всему миру и предпринимаем все необходимые меры для улучшения его функционирования. Это осуществляется путем оптимизации сети, улучшения приложения, внесения изменений в алгоритм формирования страниц, рационализации ЦОДов, уменьшения времени, требуемого для построения страниц. И все это в конечном итоге отражается на качестве обслуживания наших пользователей.

Что ж, давайте вернемся к вашему новейшему ЦОДу в Орегоне, который был недавно запущен в эксплуатацию. Чем он отличается от других?

Кан: Плотность размещения вычислительных мощностей здесь заметно выросла. Как правило, одна стойка потребляет 7-9 кВт. Но из-за ограниченного пространства нам пришлось размещать в каждой стойке гораздо больше серверов. В результате уровень энергопотребления стал превышать 14 кВт на стойку. При повышении плотности размещения оборудования растет и тепловыделение, поэтому понадобилось заново проектировать всю систему охлаждения ЦОДа. Отвод тепла теперь осуществляется через заднюю дверь. Одними из первых мы стали применять жидкостное охлаждение стойки. Конечно, на это нужны дополнительные капиталовложения, но со временем они окупаются вследствие сокращения энергопотребления.

Так вы прокачиваете через стойки воду?

Навьяр: Сначала вода охлаждается снаружи, а затем подается в теплообменник, смонтированный в задней двери. Таким образом, горячий воздух нейтрализуется прямо в стойке и у нас нет необходимости прибегать к чередованию горячих и холодных коридоров между рядами.

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

Насколько надежна прокачка воды между всеми этими системами? Вас этот вопрос беспокоит?

Навьяр: При рассмотрении новой для нас технологии соответствующие вопросы вызывали беспокойство, но мы тщательно протестировали ее, и конструкция показала себя достаточно надежной. Кроме того, мы осуществляем постоянный мониторинг, и в случае появления утечек мы бы о них знали. Но пока никаких поводов для беспокойства не возникает.

Охлаждение воды с помощью внешнего воздуха должно быть достаточно эффективным. Какова эффективность энергопотребления (Power Usage Effectiveness, PUE) у ЦОДа в Орегоне?

Навьяр: Коэффициент PUE равен 1,06. И это стоит того, если учесть, что в перспективе наша цель заключается в полном переходе на экологически чистые источники энергии. Правда, пока цель эта не достигнута, но мы стремимся к ней и во многом поэтому выбрали в Орегоне технопарк Infomart, поскольку у них есть непосредственный доступ к возобновляемым источникам энергии. (Одним из преимуществ площадки, которая была выбрана для размещения нового ЦОДа, является то, что это место позволяет использовать технологию охлаждения серверов наружным воздухом большую часть года, тем самым снижая общее потребление электроэнергии.)

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

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

Кан: Да. Проект Altair – это одно большое коммутационное решение. Его можно представить в виде большой одноуровневой сети. Здесь нет ядра, нет шасси. Представьте, что вы объединяете более 100 тыс. серверов с использованием традиционной корпоративной модели. Пакет, проходящий от одного сервера до другого, преодолевает 25-30 чипсетов и достигает цели с задержкой, измеряемой в миллисекундах. Мы сократили число промежуточных чипсетов до пяти, используя пятиярусную архитектуру Клоза Leaf-Spine, и это позволило уменьшить задержки при коммутации двух серверов до нескольких микросекунд (см. рис. 1).

В топологии Leaf-Spine все разбивается на несколько ярусов. У каждого коммутатора, смонтированного сверху стойки, есть четыре маршрута к Spine-коммутаторам, а они, в свою очередь, связываются несколькими путями с коммутаторами, расположенными над ними. Таким образом, все Spine-коммутаторы образуют одну большую коммутирующую структуру. У каждого из коммутаторов, находящихся сверху стойки, имеется четыре и более равноудаленных маршрутов ECMP (equal-cost multi-path) (см. рис. 2).

В качестве коммутаторов в верхней части стойки и Spine-коммутаторов используются одинаковые устройства?

Кан: Да, они абсолютно одинаковы. Мы перешли на единую модель учетных единиц и покупаем коммутаторы только одного типа высотой 1U.

Вы получаете все коммутаторы от одного поставщика?

Кан: Нет. Речь идет об одной платформе. Все они имеют одинаковую архитектуру и одинаковый чипсет. Одна учетная единица. У вас может быть множество поставщиков, но при этом одна платформа. Мы используем чипсет Tomahawk и 32 порта 100 Gigabit с общей пропускной способностью 3,2 Тбит/с. Канал шириной 50 Гбит/с подключается к серверам, которые могут отличаться друг от друга. Мы стали первыми, кто подает на каждый сервер поток в 10, 25 или 50, а в перспективе даже в 100 Гбит/с. И этого должно быть вполне достаточно на ближайшие четыре года, а может быть, и больше.

Все Spine-коммутаторы являются неблокируемыми, а значит, при наличии входящего 100-гигабитного канала вы всегда получаете точно такой же исходящий канал. От коммутатора вниз спускаются 50-гигабитные каналы, соответствующие стандарту PSM4. Благодаря такому решению можно взять два 100-гигабитных порта и разделить их на четыре 50-гигабитных, обеспечив эффективную пропускную способность шкафа в 200 Гбит/с.

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

Кан: Да, и серверов, и ЦОДов. Речь идет о распределении отказавших зон и упрощении инфраструктуры. При таких масштабах приходится думать о совместном использовании пространства. Приложения достаточно устойчивы к сбоям, так что мы вполне можем потерять целый шкаф, и все будет работать в рамках одного или нескольких ЦОДов.

Правильно ли я понимаю, что на коммутаторах, смонтированных в верхней части стоек, выполняется ваш собственный программный код?

Кан: На некоторых из них. Мы используем как OEM-решения (Original Equipment Manufacturer – оборудование, продаваемое компанией под своим именем и брендом, но сделанное другими предприятиями), так и оборудование собственной разработки (ODM, Original Design Manufacturer). К OEM относятся поставщики наподобие Cisco. А на оборудовании ODM выполняется наш собственный код, и мы постепенно внедряем новые мощности, монтируя новые шкафы и развертывая новые наборы баз данных.

А почему вы разрабатываете свой собственный программный код?

Кан: Есть много специфичных моментов, которыми мы желаем управлять. Нам хотелось бы сосредоточиться на управлении нашими коммутирующими структурами. Мы не ставим перед собою цель непременно разработать лучшую в мире сетевую операционную систему. Задача заключается в создании поверх аппаратного уровня приложений, которые управляли бы нашей системой коммутации.

Желательно, например, получать телеметрическую информацию с коммутатора и загружать ее на платформу машинного обучения, а полученные результаты использовать для интеллектуальной маршрутизации трафика, выявления причин снижения производительности и улучшения управления сетью. Такова наша цель. Внутри компании мы называем эту инициативу программируемым ЦОДом. Нам хочется больше узнать о сетевом уровне приложений и оптимизировать трафик внутри ЦОДа с учетом его особенностей.

Понятно. И вы поддерживаете IPv4 и v6, стремясь к повсеместному переходу на v6?

Кан: Да, на фронте v6 мы выступаем весьма активно. Несколько лет назад решено было запустить версию сайта www.linkedin.com на IPv6, с тем чтобы продолжать работу и после того, как неизбежно будут исчерпаны адреса IPv4. Мы начали с периферии и стремимся охватить рынки, оперирующие исключительно трафиком IPv6. Существенный рост использования IPv6 наблюдался в мобильном трафике. Кроме того, нам удалось добиться определенного увеличения производительности. По мере роста масштабов протокол IPv6 стал использоваться и внутри ЦОДов. В настоящее время стек v4 и v6 дублируется, но через пару лет мы планируем полностью перейти на v6.

Какова общая мощность ваших ЦОДов и как вы намерены развиваться дальше?

Навьяр: С учетом нашего корпоративного ЦОДа сегодня мы близки к 40 МВт. В следующем году постараемся еще увеличить мощности. По крайней мере, это уже запланировано. Как все будет развиваться с точки зрения интеграции с Microsoft, пока неизвестно. Сейчас в ближайших планах органичный рост, но нам, по-видимому, придется немного подождать и посмотреть, как пойдут дела дальше.

Ваша компания известна как крупный представитель сообщества open source. Какова ваша политика в этой области и в чем вы видите смысл участия в продвижении открытых платформ?

Навьяр: Хотелось бы прояснить один момент. Наша философия предусматривает определенную отдачу и открытие исходного кода проектов, над которыми мы работали, везде, где это имеет смысл. Саид уже упоминал о коммутационной телеметрии, которая выливается в очень быстрые, масштабируемые и реплицируемые потоковые приложения – настоящий конвейер сообщений. Мы открыли исходный код этого проекта, и обусловлено это сразу несколькими причинами.

От открытия нами исходного кода выигрывают другие люди, но мы убеждены в том, что это выгодно и для нашего собственного бизнеса. Во-первых, в проекты вовлекается масса новых специалистов, что приводит к улучшению получаемых результатов. А во-вторых, повышается качество работы наших инженеров. Понимая, что их программы изучают миллионы людей, они начинают ответственнее относиться к оформлению документации и выдают более элегантный код, ведь под ним ставится их подпись.

Сегодня много говорят о нашей открытой аппаратной инициативе Open19, и в следующем году здесь произойдут новые важные события. Мы решили разработать открытый стандарт 19-дюймовых стоек для серверов, систем хранения и сетевого оборудования. Цель заключается в том, чтобы вдвое сократить число общих компонентов. Все, что находится в стойке, потребляет электроэнергию и обращается к сетевым ресурсам, поэтому мы решили консолидировать все имеющиеся здесь общие компоненты.

Помимо существенной экономии капитальных затрат, Open19 поможет интегрировать стойки в два-три раза быстрее. Если у вас имеются совместно используемые блоки питания и сетевые компоненты, прокладывать громоздкие кабели уже не потребуется. Мы поддерживаем отношения со многими поставщиками OEM и ODM. Для них это выгодно, поскольку, перейдя на новый стандарт и сохраняя при этом свою интеллектуальную собственность, они придают своей перспективной базе гораздо более высокую гибкость.

Создан новый консорциум, и LinkedIn является одним из его лидеров. Формируется стратегическое партнерство. В ближайшее время комитет начнет совместную работу, а мы со своей стороны откроем архитектуру и станем продвигать предложенную инициативу.

– John Dix. Network World. LinkedIn pumps water down to its server racks, uses an interesting spine and leaf network fabric January 24, 2017