Эти два протокола долго жили в разных нишах применения, но наступило время, когда они стали конкурировать друг с другом. Мы однозначно видим, что Ethernet набирает скорость в прямом смысле слова и начинает лезть туда, где FC всегда считался единственным игроком на поле. Появились альтернативы FC, работающие на Ethernet, как в блочном доступе: IP-SAN, FCoE так и других типах, это файловый (SMB, NFS), RDMA и объектный.
Эта статья не призвана к сравнению протоколов, а скорее как краткое хронологическое описание эволюции сетей ЦОД.
* по некоторым событиям нет точных дат. Корректировки и дополнения по датам прошу присылать с удостоверяющими их ссылками. Таймлайн.
С выходом 1Gb, Ethernet теряет многие свои детские болезни, связанные с потерей фреймов. В 2002 и 2004 приняты самые популярные стандарты Ethernet 10 Gb/sec. Протокол улучшает пропускную способность с применением нового алгоритма кодирования 64b/66b (пропускная способность 10*64/64 Gb). В 2007 продано 1 миллион 10Gb портов.
Ethernet 40 Gb/sec и Ethernet 100 Gb/sec используют тот же алгоритм кодирования 64b/66b, оба стандартизированы в 2010. Некоторые производители предоставили реализацию наброска будущего стандарта 40/100 Gb ещё в 2008.
Стандарты DCB (иногда именуемых Lossless Ethernet) разрабатывались двумя независимыми группами IEEE 802.1 и IETF в период с 2008 по 2011. Два разных термина применяются в отношении продуктов доступных на рынке, базирующихся на этих стандартах: DCE и CEE:
Подробнее про DCB и CEE рекомендую почитать и позадавать вопросы, в соответствующем посте компании Cisco: "Консолидация LAN и SAN сетей ЦОД на базе протоколов DCB и FCoE".
Здесь нужно отдельно отметить, что Ethernet под передачу FC был доработан (2008-2011), при этом TRILL здесь не применим. Для реализации FCoE, были разработаны механизмы, которые имитируют buffer-to-buffer кредиты в FC, такие как: Priority Flow Control 802.1Qbb (Draft 2008, Standard 2011), Bandwidth Management 802.1Qaz (Draft 2008, Standard 2011) и Congestion Management (резерв полосы, отсутствие дропов) 802.1Qau (Draft 2006, Standard 2010). Впервые FCoE появился в коммутаторах Cisco.
FC8 на момент 2014 самый популярный среди FC и FCoE.
FC16, доступен с 2011, начал приобретать широкое распространение в 2014.
FC32, проект выпуска запланирован на 2016 (прогноз).
FC128, проект выпуска запланирован на 2016 (прогноз).
Все «чисто-блочные СХД» обзаводятся файловыми шлюзами. Знаменитая фраза «Real deal FC» (2008) бывшего руководителя одного крупного производителя СХД в то время, как бы подчёркивала, что в сетях ЦОД FC это лучший выбор. Тем не менее, IBM разрабатывает свои SONAS (2010), Hitachi покупает BlueArc (2011) для предоставления файлового доступа, EMC и HP применяют сервера с Windows для предоставления доступа по протоколу SMB и Linux для NFS. Все вышеупомянутые также теперь предоставляют возможность использования iSCSI.
Это разнообразие вариантов по сути использует Ethernet.
В 1997 Oracle с NetApp выпускают решение для БД расположенных на NAS хранилище. Файловые протоколы, использующие Ethernet, находят своё применение в высоконагруженных и критически важных приложениях. Эволюция файловых протоколов приводит к использованию Ethernet в приложениях, которые ранее использовали только блочный FC. В 2004 Oracle запускает Oracle On-Demand Austin (USA) Data Center использующий системым хранения NetApp FAS.
Microsoft разработала новую версию протокола SMB 3.0 (2012), теперь критически важные приложения как виртуализация, БД и др. могут жить в сетевой папке. Многие проихводители СХД сразу же объявляют о будущей поддержке этого протокола. В 2013 NetApp выпускает совмесно с Microsoft решение Hyper-V on SMB 3.0 и MS SQL on SMB 3.0.
В БД Oracle 11g (2007) добавлена новая функция dNFS, для расположения файлов БД в сетевой папке NFS.
NFS v4.0 (2003) — в протоколе меняется парадигма пространства имён. Теперь сервера вместо экспорта множественных файловых систем экспортируют одну псевдо-файловую систему собранную из множества реальных файловых систем и что важно, предоставляет новые возможности High-Availability для сетей ЦОД, такие как: прозрачная репликация и перемещение данных, перенаправляя клиента с одного сервера на другой; таким образом позволяя поддерживать глобальное пространство имён, при этом данные находятся и обслуживаются одним выделенным сервером. Это очень тесно взаимосвязано с построением кластерных систем и сильно упрощает их реализацию.
NFS v4.1, pNFS — (2010) параллельный NFS позволяет клиентам получать доступ к файлам через «ближайшие» линки без пере-монтирования. В 2012 компании NetApp вместе с RedHat объявляют о сотрудничестве в поддержке pNFS для Clustered Ontap и RHEL 6.2.
К преимуществам протоколов работающих поверх IP можно также отнести их возможность маршрутизации, которая дробит широковещательные домены в таких сетях. Для протоколов SMB 3.0 и NFS 4.0 архитектурно была заложена оптимизация для работы в WAN.
Выпуск конвергентных сетевых коммутаторов, таких как Cisco серии Nexus в 2009 приводит к тому, что их применение объединяет традиционную FC SAN сеть с сетью Ethernet, это позволяет более гибко IT подразделениям отвечать на изменяющиеся потребности бизнеса. Компания NetApp впервые запускает поддержку конвергентных сетей и нескольких протоколов по одному проводу (2010). Изначально передача FCoE поддерживалась только по оптике и по Twinax кабелям.
Появляются onboard 10Gb адаптеры в 2012 с «медными» портами.
Следом в 2013 появляются onboard CNA2 адаптеры второго поколения с разъемами SFP+, они могут использовать как для Ethernet, так и FC8/FC16.
Выпуск адаптеров CNA позволяет использовать FCoE и Ethernet в сетях ЦОД, предоставляя возможность получать лучшее от обоих, позволяя применять наиболее подходящие протоколы для решения различных задач.
Начало широкого применения адаптеров CNA2 (2014) в СХД NetApp, позволяющие одновременно использовать FCoE и Ethernet или «чистый» FC8/FC16. Конвергентные порты вытеснили практически все дата порты на новых системах хранения NetApp FAS8000, оставив «в чистом виде» только 1GbE. Вместе с CNA адаптерами появляются конвергентные SFP+ трансиверы, которые могут переключаться между режимами роботы FC/Ethernet, к примеру в СХД NetApp E-Series.
Объектные хранилища всё больше набирают популярности и в 2013 Seagate выпускает свои объектные жесткие диски Kinetic с Ethernet интерфейсом. А в 2014 компания HGST выпускает свои жесткие диски Open Ethernet. NetApp в 2010 году покупает StorageGRID (ранее прродукт компании Bycast Inc. ), первая инсталяция объектного хранилища 2001г.
Один из лидеров решений среди NAS кластеризации была компания Spinnaker Networks, начавшая как Start Up и поглощённая компанией NetApp в 2003, её разработки легли в основу современной ОС Clustered Ontap для СХД NetApp FAS.
Наибольшие кластера СХД предоставляющие доступ по блочному протоколу FC достигают 8 нод для NetApp FAS6200/8000, в то время как у конкурентов это обычно не более 4х нод. Для файловых протоколов число нод может быть в разы больше — 24 ноды для NetApp (2013) FAS6200/8000 (SMB, NFS). А для объектных хранилищ число нод теоретически не ограничено. В современном мире, где сравнительно не дорогие кластеризованные ноды с возможностью масштабирования по мере необходимости, могут стать более предпочтительным выбором в отличие от «подхода Mainframe», где используется один дорогой суперкомпьютер.
Максимальный размер LUN'а часто может оставлять желать лучшего: достигать 16TB и иметь ограничения по количеству LUN'ов, как на стороне хоста так и со стороны СХД. В кластерезированных СХД этот порог никуда не пропал и для получения большего объема часто применяют решения типа «костыль», объединяя несколько LUN'ов на софтверном уровне на хосте. Файловые шары могут занимать Патабайты и достаточно легко масштабироваться, получая одну огромную логическую сетевую папку в размере нескольких Петабайт, в СХД NetApp FAS это достигается при помощи технологии Infinite Volume с доступом по протоколам SMB и NFS.
Впервые технология snapshot была разработана и внедрена компанией NetApp в 1993, а технология Thin provisioning впервые была представлена в 2001 и впервые представлена в СХД 3Par в 2003 и следом у NetApp FAS в 2004. Несмотря на то, что непосредственного отношения эти две технологии не имеют ни к Ethernet с его SMB, NFS ни к FC, всё же в плане удобства использования Thin Provisioning и Snapshots «на стыке» с «файловыми» и «блочными» протоколами очень отличаются друг от друга.
Так к примеру, если у вас используется «тонкий» LUN и при этом место на СХД «на самом деле» закончилось, все приличные СХД переведут такой LUN в режим офлайн, чтобы приложение не пыталось туда писать и не испортило данные на нём. Аналогичная ситуация произойдёт когда снепшоты «съедят» всё пространство актуальной файловой системы и не оставят место для самих данных в тонком LUN'е. Также неприятной особенностью «тонких» LUN'ов всегда было то, что он всегда «растёт», даже если данные удаляются на уровне файловой системы живущей «поверх» LUN'а, хранилище этого LUN'а ничего об этом не знает.
В то же время для файловых шар тонкое планирование предоставляется, что говориться «by design» и уж точно окончание пространства не переведёт сетевую папку в офлайн.
Так в ОС Windows 2012, RedHat Enterprise Linux 6.2 (2011) и VMWare 5.0 (2011) могут запускать функцию Logical Block Provisioning как определено в стандарте SCSI SBC-3 (что часто называют SCSI thin provisioning), который «объясняет» ОС, что LUN на самом деле «тонкий» и место на нём «на самом деле закончилось», запрещая проводить операции записи. Таким образом, ОС должна перестать писать в такой LUN, а он сам не будет переведён в офлайн и останется доступен только на чтение (другой вопрос как на это отреагирует приложение). Этот функционал также предоставляет возможность использования Space Reclamation, который позволяет LUN'ам уменьшаться, после удаления актуальных данных на нём. Таким образом, LUN'ы теперь более адекватно работают в режиме тонкого планирования. Так спустя 8 лет «Thin Provisioning Awareness» докатился от СХД (2003) до хоста (2011).
Что касается кластеризированных решений для хостов, то в отличие от сетевых папок, с одним LUN'ом долгое время мог работать (читать и писать) только один хост. Все остальные хосты могли только лишь читать этот LUN. Но и здесь пришло решение спустя время, Block или Region Level Locking Mechanism — можно разбивать LUN на логические участки и предоставляя нескольким хостам возможность писать только в «свои» участки. В то время как у сетевых папок эта функция заложена в дизайн протокола и присутствовала с самого возникновения.
С другой стороны у сетевых папок не было никогда функциональности на подобии Multipathing, которая позволяла бы клиенту запрашивающему файл, обращаться к нему по нескольким путям или по кратчайшему пути. Этого всегда не хватало файловым протоколам, так появился pNFS, частично этот недостаток закрывался LACP, позволяя балансировать трафик между несколькими коммутаторами при помощи технологии vPC.
По-видимому, функционал всё дальше будет заимствоваться, сближая протоколы. Конвергенция видится неизбежным будущим в виду перечисленных выше событий. Это заставит два протокола ещё более жестко бороться за сферы применения в сетях ЦОД. Реализация кластерных СХД с доступом по блочному FC протоколу имеет более сложную архитектуру, технические ограничения по размеру LUN'а и их количеству, что не играют в пользу будущего развития этого протокола в современном мире постоянно растущих данных и парадигме кластеризации, требуя доразвития в этом направлении. Также Ethernet очень опережает по скорости FC, что может сказаться на будущем последнего, в связи с чем есть предположение что FC сместиться внутрь Ethernet и останется жить там, в виде FCoE. Ведь по сути разница в 8мь лет: 100Gb 2008 и 128Gb в 2016. Выбирая между FC и FCoE обратите внимание на эту статью.
Хочу отметить, что здесь не рассматривались не распространённые варианты типа IP поверх FC и прочих всевозможных сочетаний протоколов, а только наиболее часто использующиеся комбинаций протоколов в инфраструктурных дизайнах ЦОД, которые и формируют тренды будущего.
Сообщения по ошибкам в тексте прошу направлять в ЛС.
Замечания и дополнения напротив прошу в комментарии
Эта статья не призвана к сравнению протоколов, а скорее как краткое хронологическое описание эволюции сетей ЦОД.
* по некоторым событиям нет точных дат. Корректировки и дополнения по датам прошу присылать с удостоверяющими их ссылками. Таймлайн.
Проблемы Ethernet
С выходом 1Gb, Ethernet теряет многие свои детские болезни, связанные с потерей фреймов. В 2002 и 2004 приняты самые популярные стандарты Ethernet 10 Gb/sec. Протокол улучшает пропускную способность с применением нового алгоритма кодирования 64b/66b (пропускная способность 10*64/64 Gb). В 2007 продано 1 миллион 10Gb портов.
Ethernet 40 Gb/sec и Ethernet 100 Gb/sec используют тот же алгоритм кодирования 64b/66b, оба стандартизированы в 2010. Некоторые производители предоставили реализацию наброска будущего стандарта 40/100 Gb ещё в 2008.
Data Center Bridging
Стандарты DCB (иногда именуемых Lossless Ethernet) разрабатывались двумя независимыми группами IEEE 802.1 и IETF в период с 2008 по 2011. Два разных термина применяются в отношении продуктов доступных на рынке, базирующихся на этих стандартах: DCE и CEE:
Подробнее про DCB и CEE рекомендую почитать и позадавать вопросы, в соответствующем посте компании Cisco: "Консолидация LAN и SAN сетей ЦОД на базе протоколов DCB и FCoE".
Converged Enhanced Ethernet
Здесь нужно отдельно отметить, что Ethernet под передачу FC был доработан (2008-2011), при этом TRILL здесь не применим. Для реализации FCoE, были разработаны механизмы, которые имитируют buffer-to-buffer кредиты в FC, такие как: Priority Flow Control 802.1Qbb (Draft 2008, Standard 2011), Bandwidth Management 802.1Qaz (Draft 2008, Standard 2011) и Congestion Management (резерв полосы, отсутствие дропов) 802.1Qau (Draft 2006, Standard 2010). Впервые FCoE появился в коммутаторах Cisco.
Перспективы скоростей для FC
FC8 на момент 2014 самый популярный среди FC и FCoE.
FC16, доступен с 2011, начал приобретать широкое распространение в 2014.
FC32, проект выпуска запланирован на 2016 (прогноз).
FC128, проект выпуска запланирован на 2016 (прогноз).
«Чисто-блочные» СХД
Все «чисто-блочные СХД» обзаводятся файловыми шлюзами. Знаменитая фраза «Real deal FC» (2008) бывшего руководителя одного крупного производителя СХД в то время, как бы подчёркивала, что в сетях ЦОД FC это лучший выбор. Тем не менее, IBM разрабатывает свои SONAS (2010), Hitachi покупает BlueArc (2011) для предоставления файлового доступа, EMC и HP применяют сервера с Windows для предоставления доступа по протоколу SMB и Linux для NFS. Все вышеупомянутые также теперь предоставляют возможность использования iSCSI.
Это разнообразие вариантов по сути использует Ethernet.
Файловые протоколы поверх Ethernet
В 1997 Oracle с NetApp выпускают решение для БД расположенных на NAS хранилище. Файловые протоколы, использующие Ethernet, находят своё применение в высоконагруженных и критически важных приложениях. Эволюция файловых протоколов приводит к использованию Ethernet в приложениях, которые ранее использовали только блочный FC. В 2004 Oracle запускает Oracle On-Demand Austin (USA) Data Center использующий системым хранения NetApp FAS.
Microsoft разработала новую версию протокола SMB 3.0 (2012), теперь критически важные приложения как виртуализация, БД и др. могут жить в сетевой папке. Многие проихводители СХД сразу же объявляют о будущей поддержке этого протокола. В 2013 NetApp выпускает совмесно с Microsoft решение Hyper-V on SMB 3.0 и MS SQL on SMB 3.0.
В БД Oracle 11g (2007) добавлена новая функция dNFS, для расположения файлов БД в сетевой папке NFS.
NFS v4.0 (2003) — в протоколе меняется парадигма пространства имён. Теперь сервера вместо экспорта множественных файловых систем экспортируют одну псевдо-файловую систему собранную из множества реальных файловых систем и что важно, предоставляет новые возможности High-Availability для сетей ЦОД, такие как: прозрачная репликация и перемещение данных, перенаправляя клиента с одного сервера на другой; таким образом позволяя поддерживать глобальное пространство имён, при этом данные находятся и обслуживаются одним выделенным сервером. Это очень тесно взаимосвязано с построением кластерных систем и сильно упрощает их реализацию.
NFS v4.1, pNFS — (2010) параллельный NFS позволяет клиентам получать доступ к файлам через «ближайшие» линки без пере-монтирования. В 2012 компании NetApp вместе с RedHat объявляют о сотрудничестве в поддержке pNFS для Clustered Ontap и RHEL 6.2.
К преимуществам протоколов работающих поверх IP можно также отнести их возможность маршрутизации, которая дробит широковещательные домены в таких сетях. Для протоколов SMB 3.0 и NFS 4.0 архитектурно была заложена оптимизация для работы в WAN.
Конвергентные устройства
Выпуск конвергентных сетевых коммутаторов, таких как Cisco серии Nexus в 2009 приводит к тому, что их применение объединяет традиционную FC SAN сеть с сетью Ethernet, это позволяет более гибко IT подразделениям отвечать на изменяющиеся потребности бизнеса. Компания NetApp впервые запускает поддержку конвергентных сетей и нескольких протоколов по одному проводу (2010). Изначально передача FCoE поддерживалась только по оптике и по Twinax кабелям.
Появляются onboard 10Gb адаптеры в 2012 с «медными» портами.
Следом в 2013 появляются onboard CNA2 адаптеры второго поколения с разъемами SFP+, они могут использовать как для Ethernet, так и FC8/FC16.
Выпуск адаптеров CNA позволяет использовать FCoE и Ethernet в сетях ЦОД, предоставляя возможность получать лучшее от обоих, позволяя применять наиболее подходящие протоколы для решения различных задач.
Начало широкого применения адаптеров CNA2 (2014) в СХД NetApp, позволяющие одновременно использовать FCoE и Ethernet или «чистый» FC8/FC16. Конвергентные порты вытеснили практически все дата порты на новых системах хранения NetApp FAS8000, оставив «в чистом виде» только 1GbE. Вместе с CNA адаптерами появляются конвергентные SFP+ трансиверы, которые могут переключаться между режимами роботы FC/Ethernet, к примеру в СХД NetApp E-Series.
Объектные хранилища поверх Ethernet
Объектные хранилища всё больше набирают популярности и в 2013 Seagate выпускает свои объектные жесткие диски Kinetic с Ethernet интерфейсом. А в 2014 компания HGST выпускает свои жесткие диски Open Ethernet. NetApp в 2010 году покупает StorageGRID (ранее прродукт компании Bycast Inc. ), первая инсталяция объектного хранилища 2001г.
Масштабирование и кластеризация
Один из лидеров решений среди NAS кластеризации была компания Spinnaker Networks, начавшая как Start Up и поглощённая компанией NetApp в 2003, её разработки легли в основу современной ОС Clustered Ontap для СХД NetApp FAS.
Наибольшие кластера СХД предоставляющие доступ по блочному протоколу FC достигают 8 нод для NetApp FAS6200/8000, в то время как у конкурентов это обычно не более 4х нод. Для файловых протоколов число нод может быть в разы больше — 24 ноды для NetApp (2013) FAS6200/8000 (SMB, NFS). А для объектных хранилищ число нод теоретически не ограничено. В современном мире, где сравнительно не дорогие кластеризованные ноды с возможностью масштабирования по мере необходимости, могут стать более предпочтительным выбором в отличие от «подхода Mainframe», где используется один дорогой суперкомпьютер.
Максимальный размер LUN'а часто может оставлять желать лучшего: достигать 16TB и иметь ограничения по количеству LUN'ов, как на стороне хоста так и со стороны СХД. В кластерезированных СХД этот порог никуда не пропал и для получения большего объема часто применяют решения типа «костыль», объединяя несколько LUN'ов на софтверном уровне на хосте. Файловые шары могут занимать Патабайты и достаточно легко масштабироваться, получая одну огромную логическую сетевую папку в размере нескольких Петабайт, в СХД NetApp FAS это достигается при помощи технологии Infinite Volume с доступом по протоколам SMB и NFS.
ThinProvitioning & Snapsots
Впервые технология snapshot была разработана и внедрена компанией NetApp в 1993, а технология Thin provisioning впервые была представлена в 2001 и впервые представлена в СХД 3Par в 2003 и следом у NetApp FAS в 2004. Несмотря на то, что непосредственного отношения эти две технологии не имеют ни к Ethernet с его SMB, NFS ни к FC, всё же в плане удобства использования Thin Provisioning и Snapshots «на стыке» с «файловыми» и «блочными» протоколами очень отличаются друг от друга.
Так к примеру, если у вас используется «тонкий» LUN и при этом место на СХД «на самом деле» закончилось, все приличные СХД переведут такой LUN в режим офлайн, чтобы приложение не пыталось туда писать и не испортило данные на нём. Аналогичная ситуация произойдёт когда снепшоты «съедят» всё пространство актуальной файловой системы и не оставят место для самих данных в тонком LUN'е. Также неприятной особенностью «тонких» LUN'ов всегда было то, что он всегда «растёт», даже если данные удаляются на уровне файловой системы живущей «поверх» LUN'а, хранилище этого LUN'а ничего об этом не знает.
В то же время для файловых шар тонкое планирование предоставляется, что говориться «by design» и уж точно окончание пространства не переведёт сетевую папку в офлайн.
Заимствование функционала
Так в ОС Windows 2012, RedHat Enterprise Linux 6.2 (2011) и VMWare 5.0 (2011) могут запускать функцию Logical Block Provisioning как определено в стандарте SCSI SBC-3 (что часто называют SCSI thin provisioning), который «объясняет» ОС, что LUN на самом деле «тонкий» и место на нём «на самом деле закончилось», запрещая проводить операции записи. Таким образом, ОС должна перестать писать в такой LUN, а он сам не будет переведён в офлайн и останется доступен только на чтение (другой вопрос как на это отреагирует приложение). Этот функционал также предоставляет возможность использования Space Reclamation, который позволяет LUN'ам уменьшаться, после удаления актуальных данных на нём. Таким образом, LUN'ы теперь более адекватно работают в режиме тонкого планирования. Так спустя 8 лет «Thin Provisioning Awareness» докатился от СХД (2003) до хоста (2011).
Что касается кластеризированных решений для хостов, то в отличие от сетевых папок, с одним LUN'ом долгое время мог работать (читать и писать) только один хост. Все остальные хосты могли только лишь читать этот LUN. Но и здесь пришло решение спустя время, Block или Region Level Locking Mechanism — можно разбивать LUN на логические участки и предоставляя нескольким хостам возможность писать только в «свои» участки. В то время как у сетевых папок эта функция заложена в дизайн протокола и присутствовала с самого возникновения.
С другой стороны у сетевых папок не было никогда функциональности на подобии Multipathing, которая позволяла бы клиенту запрашивающему файл, обращаться к нему по нескольким путям или по кратчайшему пути. Этого всегда не хватало файловым протоколам, так появился pNFS, частично этот недостаток закрывался LACP, позволяя балансировать трафик между несколькими коммутаторами при помощи технологии vPC.
Заключение
По-видимому, функционал всё дальше будет заимствоваться, сближая протоколы. Конвергенция видится неизбежным будущим в виду перечисленных выше событий. Это заставит два протокола ещё более жестко бороться за сферы применения в сетях ЦОД. Реализация кластерных СХД с доступом по блочному FC протоколу имеет более сложную архитектуру, технические ограничения по размеру LUN'а и их количеству, что не играют в пользу будущего развития этого протокола в современном мире постоянно растущих данных и парадигме кластеризации, требуя доразвития в этом направлении. Также Ethernet очень опережает по скорости FC, что может сказаться на будущем последнего, в связи с чем есть предположение что FC сместиться внутрь Ethernet и останется жить там, в виде FCoE. Ведь по сути разница в 8мь лет: 100Gb 2008 и 128Gb в 2016. Выбирая между FC и FCoE обратите внимание на эту статью.
Хочу отметить, что здесь не рассматривались не распространённые варианты типа IP поверх FC и прочих всевозможных сочетаний протоколов, а только наиболее часто использующиеся комбинаций протоколов в инфраструктурных дизайнах ЦОД, которые и формируют тренды будущего.
Сообщения по ошибкам в тексте прошу направлять в ЛС.
Замечания и дополнения напротив прошу в комментарии