ЦОД

Согласно отчету Uptime Institute, в последние годы перебои в работе цифровой инфраструктуры обходятся все дороже и дороже. При этом общее количество крупных отключений осталось прежним, а следовательно, суммы, затрачиваемые в среднем на восстановление работоспособности после сбоя, растут.

Доля отдельных отключений, приводящих к убыткам на сумму свыше 100 тыс. долл., в 2021 году увеличилась до 47% по сравнению с 40%, о которых шла речь годом ранее. Хотя среднюю стоимость одного отключения в Uptime Institute не рассчитывают, общие тенденции указывают на то, что затраты на преодоление последствий такого отключения продолжают расти.

Каждое пятое предприятие сообщило по крайней мере об одном «серьезном» сбое за последние три года. Речь идет об отключениях, которые привели к существенным финансовым потерям, телесным повреждениям, репутационному ущербу или нарушениям требований законодательства. 80% участников опроса сообщили о возникновении у них сбоев в последние три года (без конкретизации уровня их серьезности), что находится на верхней границе нормы.

В отчете отмечается, что наибольшая доля отключений в целом была вызвана проблемами, которые связаны с сетью и могут быть результатом крупномасштабного перехода на облачные технологии, технологии программно-конфигурируемых сетей (software defined networking, SDN) и другие новые сетевые архитектуры.

Но наиболее ощутимые неприятности, как правило, связаны со сбоями в электроснабжении. На них приходится 43% «серьезных» отключений за последние три года.

Согласно отчету, наибольшее количество перебоев в обслуживании в рассматриваемый период наблюдалось у независимых поставщиков услуг. На долю облачных провайдеров, поставщиков услуг хостинга, связи и телекоммуникационных компаний приходится почти две трети всех отключений общедоступных сервисов, которые Uptime Institute отслеживал на протяжении последних семи лет. К 2021 году эти показатели увеличились на 70%.

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

По словам основателя и исполнительного директора Uptime Institute Энди Лоуренса, виновата в высоком уровне сбоев (как прямо, так и косвенно) все более сложная архитектура современных ИТ.

«Отсутствие заметных улучшений в общем уровне сбоев в определенной степени является результатом огромных недавних инвестиций в цифровую инфраструктуру и всех сложностей, с которыми сталкиваются операторы при переходе на гибридные распределенные архитектуры, – подчеркнул Лоуренс. – Со временем как технологии, так и операционные процессы будут улучшаться, но пока перебои в работе остаются главной проблемой для клиентов, инвесторов и регуляторов».

Отчет Uptime Institute опирается на несколько видов источников — от публичных отчетов о крупных сбоях и результатов специальных опросов до баз данных об аномальных инцидентах, которые ведет компания.

Сбои в работе дата-центров происходят в последнее время регулярно, но далеко не все из них попадают в поле зрения общественности. Чаще всего их замечают, если провайдеры не могут устранить последствия длительное время (более одного дня), либо если проблема касается очень большого количества пользователей. Так недавно было с Twitter, а также Facebook, Instagram и WhatsApp. Для этих сервисов недоступность даже в двадцать минут чревата народным негодованием.

Однако пожары все же стоят особняком от прочих инцидентов, вызывающих простой информационных систем. Дело в том, что они случаются достаточно редко, но при этом не остаются незамеченным. Сложно игнорировать, когда полыхает крыша (или здание целиком, как в случае в OVH), прямо на глазах у публики.

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

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

Сложно представить, что такой востребованный среди клиентов объект, как дата-центр в Страсбурге, был построен с нарушением норм противопожарной безопасности. Подобные площадки проектируются и возводятся в строгом соответствии со стандартами Uptime Institute. Из этого можно сделать вывод, что скорее всего проблема кроется именно в неправильной эксплуатации.

Между тем, принципы обслуживания ЦОД также зафиксированы в стандартах Uptime Institute. В комплексе они позволяют свести практически к минимуму количество возможных инцидентов в дата-центре. Например, в них прописаны регламенты доступа в здание, проведения регламентных работ и т. д. Следуя им, можно обеспечить постоянную доступность объекта на протяжении десятков лет.

Как компаниям застраховать себя от простоев и потери информации

Рекомендации здесь универсальные. Во-первых, стоит обращать внимание на наличие сертификатов Uptime Institute. Предпочтительнее будут те провайдеры, которые смогут предоставить полный комплект документов, включая актуальный сертификат на операционную устойчивость (Tier Certification of Operational Sustainability Uptime Institute). Именно он свидетельствует о грамотно выстроенных процессах эксплуатации.

Во-вторых, при выборе поставщика услуги рекомендуется лично посещать объект. Незазорно попросить провести экскурсию, в том числе на крышу здания, и оценить, как соблюдается порядок в помещениях, не относящихся напрямую к серверным.

Наконец, нельзя забывать про планы восстановления в случае аварий (DRP), регулярно обновлять их в соответствии с новыми рисками, выполнять тестовые переключения, или даже резервировать данные, используя технологии High Availability. Последнее позволит восстановиться на независимой площадке за короткое время, даже если на основной ЦОД упадет метеорит.

Автор — Павел Колмычек, операционный директор КРОК Облачные сервисы

В АО «Медицина» (клиника академика Ройтберга) стремятся использовать весь арсенал информационных технологий для повышения клиентоориентированности бизнеса. Это стремление находит отражение и в инфраструктурных проектах. О самом последнем из них Максим Петухов, ИТ-директор АО «Медицина» (клиника академика Ройтберга), расскажет на форуме ИНФРАСТРУКТУРА 2019, которую издательство «Открытые системы» проведет 18 июня. А пока он ответил на несколько вопросов CIO.ru.

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

- Клиника создавала инженерную и ИТ-инфраструктуру с запасом, но мир с каждым днем меняется все динамичнее. Хватает ли сегодня того «запаса», чтобы поддержать дальнейшее развитие бизнеса?

Бесконечный запас расширения создать невозможно, он ограничен средним временем жизни технологий. Если для софта можно все время поддерживать актуальную версию, то «железо» однозначно стареет.

Тот запас, который мы закладывали при проектировании инфраструктуры, по-прежнему играет свою роль. Мы спокойно увеличили там, где нужно было, количество компьютеров, которые подключаются к проводной сети. Возможности, которые были заложены в ЦОДе по размещению оборудования, нас устраивают.

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

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

1.  
2.  
3.  
4.  

Пред.След.

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

- Как часто бизнес ставит перед ИТ-службой клиники задачи, требующие модернизации инфраструктуры?

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

Только предусмотрительность, проявленная при проектировании, позволяет пользоваться плодами инфраструктурных проектов на протяжении длительного времени.

- Какими подходами вы руководствуетесь в управлении инфраструктурой? Много ли внимания вы ей уделяете?

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

Мы используем две системы мониторинга. Первая, приобретенная вместе с сетевым оборудованием Hewlett-Packard, служит для его мониторинга, контроля изменений конфигураций. Вторая, Zabbix, более универсальна и позволяет отслеживать параметры всего оборудования и информационных систем. Недели не проходит, чтобы мы не ввели в нее какой-то новый параметр или сценарий работы оповещений. Это та система, которую мы все время наращиваем.

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

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

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

Поэтому при внедрении новых систем и попытке сократить затраты на действующие мы исследуем и проводим расчеты для всех современных технологий. Облака — одна из них. Пока мы не увидели такого предложения, которое позволит сэкономить существенные средства: повторюсь, в клинике построена очень серьезная инфраструктура, многое сделано с запасом. Нам не интересно брать вычислительные мощности из облака, потому что выгоднее загрузить свои. Но мы присматриваемся ко всему, и одно из интересных перспективных направлений — возможность долговременного хранения зашифрованных резервных копий информационных систем, а также данных систем видеонаблюдения, которые занимают очень большой объем, и архивов медицинских исследований — КТ и ПЭТ/КТ. То есть тех данных, которые можно спокойно перенести «на холод», так как даже ленточные накопители требуют определенных параметров хранения: влажности, температурного режима.

- Что вы расскажете участникам конференции «Инфраструктура» и что вам самому будет интересно?

Сосредоточусь на проекте обновления сети Wi-Fi. Интересно, что немаловажную роль в принятии решения об этих инвестициях сыграли пациенты, высказав свое мнение, которое утвердило нас в необходимости этого проекта. Это важно для ИТ-директоров и для владельцев бизнеса.

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

Для поддержки полумиллиарда пользователей 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