Комментарии 17
Сколько раз говорил — не пускайте маркетологов писать «технические» статьи.
«Когда вы в последний раз слышали о взломе сети Fibre Channel? Никогда? Как насчет сети Ethernet?»
Вы выдаете принцип security through obscurity за правильный подход.
FC ломается легко и просто, «спасает» изолированность — но на ethernet легко можно сделать то-же самое, с намного более высокими скоростями передачи данных (сотни гигабит) и меньшими задержками (FC коммутаторы в 2-3 раза выше уровень задержек / latency)
«и с IOPS, превышающим один миллион» — миллион — это много по вашему? Да сегодня одна NVMe / Optane карта больше может выдавать.
Мы еще в 2017 году показывали как в VM легко получается более миллиона IOPS, на SDS с чистыми ethernet подключениями.
Про tcp/ip — тоже крайне неграмотно, изучайте что такое RDMA, RoCE v2 и тд.
…
Ни одна из крупных онлайн компаний не использует FC (да и традиционные СХД)
Существовала одна компания, которая пыталась это делать — Yahoo. Теперь ее нет, они проиграли технологическую гонку c Google.
Вот хорошая статья на эту тему (почему Yahoo умер).
techcrunch.com/2016/05/22/why-google-beat-yahoo-in-the-war-for-the-internet
«At the beginning of the new millennium, Google and Yahoo started down very different paths to attain the enormous scale that the growing size and demands of the Internet economy (search, email, maps, etc.) required. For Yahoo, the solution came in the form of NetApp filers, which allowed the company to add server space at a dizzying rate. Almost every service that Yahoo offered ultimately ran on NetApp’s purpose-built storage appliances, which were quick to set up and easy to use, giving Yahoo a fast track to meet market demand (and soon made the company NetApp’s largest customer).
But in nearby Mountain View, Google began work on engineering its own software-defined infrastructure, ultimately known as the Google File System, „
Гораздо больше вендоров, гораздо больше средств анализа трафика и борьбы со злоумышленниками (включая DPI / firewall), гораздо больше возможностей (гибкость).
По сути, если сравнить распространение FC SAN сетей и ethernet — вторые будут на несколько порядков (буквально) более распространены — например, все онлайн бизнесы (в сумме обслуживающие многие миллиарды пользователей).
Ни одна «энтерпрайз» платформа даже рядом не лежит с тем же гугл или фейсбук например.
В приведённой Вами цитате речь идёт о файлерах NetApp. Разве они используют SAN?
Что же это, получается вы в Simplivity используете не предназначенный для этого протокол?
Поскольку Fibre Channel изначально был разработан для трафика хранилищ
Это не так. Fibre Channel разрабатывался как замена 100-мегабитному Ethernet'у. Но вместо этого победил гигабитный Ethernet, и стандарт отправили на полку. И лишь когда IBM стала разрабатывать стандарт SSA взамен отживающему свое параллельному SCSI, производители жестких дисков во главе c Seagate встрепенулись (т.к. не хотели платить IBM копеечку с каждого жесткого диска) и решили откопать стандарт Fibre Channel, доработав его для использования в СХД. Именно они добавили туда топологию петли, широко использовавшуюся в СХД (изначально было только 2 топологии — фабрика и P2P).
сети Fibre Channel не так подвержены нарушениям безопасности, как Ethernet
Атаки на SAN — это полное раздолье для хакеров.
Погуглите bh-us-03-dwivedi.pdf – документ аж от 2003 года, но все актуально и сейчас.
Расписаны WWN spoofing, session hijacking, MiTM и DoS.
Шифрования нет, все открытым текстом. Аутентификации тоже обычно нет — красота!
В фабрике есть такие классные сервисы, как Management Server и Name Server, которые с радостью выложат любому информацию о фабрике и подключенных устройствах.
Доступ дается на основе WWN. Это все равно, что выдавать доступ хостам на основе их MAC-адресов. Кто-то скажет, что в Fibre Channel есть возможность аутентификации. Но обычно никто этого не использует, т.к. не все устройства это умеют (например, если это блэйды с NPIV — то все печально).
community.hpe.com/t5/Around-the-Storage-Block/Fibre-Channel-The-lifeblood-of-storage-connectivity-in-the-data/ba-p/7046140
Единственная реальная разница в стоимости между FC и iSCSI – это когда DAC — кабели используются в реализациях iSCSI. Но с ограничением расстояния 5 метров, используя DAC — кабели.
Ох и завернули триллер… в оригинале тоже муть. Может кто-то пояснить мысль сего?
Понять сие не сложно. Автор повествует, что напрасно многие думают, что iSCSI дешевле FC из-за того, что с iSCSI не нужна отдельная сеть SAN. Для достижения должного уровня производительности iSCSI все равно приходится изолировать от обычного сетевого трафика тем или иным способом. Например, VLAN'ами, или ставить отдельные коммутаторы Ethernet. Т.е. получается такая же отдельная сеть SAN, как и с FC. Единственный случай, когда iSCSI реально дешевле FC — это когда сервера подключаются к СХД напрямую (без коммутатора) медным твинаксиальным кабелем SFP+, который используется в 10Gb Ethernet. HP это называет DAC (Direct Attached Cable). Там расстояние ограничено 5 метрами.
1. Не обязательно напрямую подключать сервера с СХД. 10Гбит Ethernet Switch всяко дешевле FC Switch-a.
Можно и напрямую конечно, если не ферма. Просто в случае с vSphere уже не получается использовать Host Profiles, а это грустно.
2. Доходит и до 7м. Можно между шкафами пробрасывать, если недалеко.
dustinweb.azureedge.net/media/206922/x240-10g-sfp-sfp-3m-dac-cable.pdf
Например, Cisco
Правда, это уже активные кабеля, медные или оптические. Они дороже, но всё же сильно дешевле набора из двух SFP+ с патч-кордом.
Fibre Channel: жизненная сила подключения к хранилищам в центре обработки данных