Майбутнє Ethernet & FC

Ці два протоколи довго жили в різних нішах застосування, але настав час, коли вони стали конкурувати один з одним. Ми однозначно бачимо, що Ethernet набирає швидкість в прямому сенсі слова і починає лізти туди, де FC завжди вважався єдиним гравцем на полі. З'явилися альтернативи FC, що працюють на Ethernet, як у блочному доступі: IP-SAN, FCoE так і інших типах, це файловий (SMB, NFS), RDMA і об'єктний.

Ця стаття не покликана до порівняння протоколів, а скоріше як короткий хронологічний опис еволюції мереж ЦОД.

* за деякими подіями немає точних дат. Коригування та доповнення за датами прошу надсилати з засвідчуючими їх посиланнями. Таймлайн.

Проблеми 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 році купує StorceGRID (раніше прродукт компанії 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'a часто може залишати бажати кращого: досягати 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'e. Також неприємною особливістю «тонких» LUN'ів завжди було те, що він завжди «росте», навіть якщо дані видаляються на рівні файлової системи живої «поверх» LUN'a, сховище цього LUN'a нічого про це не знає.

У той же час для файлових куль тонке планування надається, що говоритися «by design» і вже точно закінчення простору не переведе мережеву теку в офлайн.

Запозичення функціоналу

Так в ОС Windows 2012, RedHat Enterprise Linux 6.2 (2011) і VMWare 5.0 (2011) можуть запускати функцію Logical Block Provisioning як визначено в стандарті SCSI SBC-3 (що часто називають SCSI thin provisioning), який «пояснює» ОLс «Насправді», «, що», Насправді «»,, «, Що»,, «», Насправді, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, «»,, Таким чином, ОС повинна перестати писати в такій 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'a і їх кількістю, що не грають на користь майбутнього розвитку цього протоколу в сучасному світі постійно зростаючих даних і парадигмі кластеризації, вимагаючи дорозвитку в цьому напрямку. Також Ethernet дуже випереджає за швидкістю FC, що може позначитися на майбутньому останнього, у зв'язку з чим є припущення що FC зміститися всередину Ethernet і залишиться жити там, у вигляді FCoE. Адже по суті різниця в 8мь років: 100Gb 2008 і 128Gb в 2016. Вибираючи між FC і FCoE зверніть увагу на цю статтю.

Хочу зазначити, що тут не розглядалися не поширені варіанти типу IP поверх FC та інших всіляких поєднань протоколів, а тільки найбільш часто використовувані комбінації протоколів в інфраструктурних дизайнах ЦОД, які і формують тренди майбутнього.

Повідомлення помилково в тексті прошу надсилати до ЛС.

Зауваження та доповнення навпроти прошу в коментарі