当社はデータインフラストラクチャの将来を開拓しています。

Posts Tagged 'Ethernet network'

• January 29, 2021

  

  

  

  全速力で前進！ マーベルのイーサネット・デバイス・ブリッジがAvnu認証を取得

  マーベル、オートモーティブ・ビジネス・ユニット、マーケティング担当副社長、アミール・バー・ニヴと マーベル、オートモーティブ・ビジネス・ユニット、シニアプロダクト・マーケティング・マネージャー ジョン・バーゲン共著

  アメリカの鉄道建設の初期には、競合する各社がそれぞれ異なる幅で線路を敷設していた。 このような一貫性のない規格は非効率を招き、鉄道会社間の車両の容易な交換を妨げ、インフラが全国的なネットワークに統合されるのを妨げた。 ようやく1860年代に、4フィート8インチ1/2インチという全国的な規格が誕生して初めて、鉄道はネットワーク化された真の潜在能力を発揮し始めた。

  それから約160年後、マーベルとその競合他社が世界の交通網の改革を競い合う中、ユニバーサルデザイン基準はかつてないほど重要になっている。 最近、マーベルの88Q5050 Ethernet Device Bridge は、車載業界で初めてAvnu認証を取得した。これは、今日のデータ依存型自動車のスムーズで安全かつ信頼性の高い運行を可能にする、多様な車載ネットワーク間の情報交換を促進する厳しい新しい技術標準を満たすものである。

  続きを読む
• November 01, 2020

  

  

  

  ボーダレス・エンタープライズにおける優れたパフォーマンス - ホワイトペーパー

  By Gidi Navon, Senior Principal Architect, Marvell

  
  
  The current environment and an expected “new normal” are driving the transition to a borderless enterprise that must support increasing performance requirements and evolving business models. The infrastructure is seeing growth in the number of endpoints (including IoT) and escalating demand for data such as high-definition content. Ultimately, wired and wireless networks are being stretched as data-intensive applications and cloud migrations continue to rise.

  続きを読む
• March 02, 2018

  

  

  

  Connecting Shared Storage – iSCSI or Fibre Channel

  By Todd Owens, Field Marketing Director, Marvell

  At Cavium, we provide adapters that support a variety of protocols for connecting servers to shared storage including iSCSI, Fibre Channel over Ethernet (FCoE) and native Fibre Channel (FC). One of the questions we get quite often is which protocol is best for connecting servers to shared storage? The answer is, it depends. 

  We can simplify the answer by eliminating FCoE, as it has proven to be a great protocol for converging the edge of the network (server to top-of-rack switch), but not really effective for multi-hop connectivity, taking servers through a network to shared storage targets. That leaves us with iSCSI and FC. 

  Typically, people equate iSCSI with lower cost and ease of deployment because it works on the same kind of Ethernet network that servers and clients are already running on. These same folks equate FC as expensive and complex, requiring special adapters, switches and a “SAN Administrator” to make it all work. 

  This may have been the case in the early days of shared storage, but things have changed as the intelligence and performance of the storage network environment has evolved. What customers need to do is look at the reality of what they need from a shared storage environment and make a decision based on cost, performance and manageability. For this blog, I’m going to focus on these three criteria and compare 10Gb Ethernet (10GbE) with iSCSI hardware offload and 16Gb Fibre Channel (16GFC). 

  Before we crunch numbers, let me start by saying that shared storage requires a dedicated network, regardless of the protocol. The idea that iSCSI can be run on the same network as the server and client network traffic may be feasible for small or medium environments with just a couple of servers, but for any environment with mission-critical applications or with say four or more servers connecting to a shared storage device, a dedicated storage network is strongly advised to increase reliability and eliminate performance problems related to network issues. 

  Now that we have that out of the way, let’s start by looking at the cost difference between iSCSI and FC. We have to take into account the costs of the adapters, optics/cables and switch infrastructure. Here’s the list of Hewlett Packard Enterprise (HPE) components I will use in the analysis. All prices are based on published HPE list prices.

    Notes: 1. Optical transceiver needed at both adapter and switch ports for 10GbE networks. Thus cost/port is two times the transceiver cost 2. FC switch pricing includes full featured management software and licenses 3. FC Host Bus Adapters (HBAs) ship with transceivers, thus only one additional transceiver is needed for the switch port 

  So if we do the math, the cost per port looks like this: 

  10GbE iSCSI with SFP+ Optics = $437+$2,734+$300 = $3,471 

  10GbE iSCSI with 3 meter Direct Attach Cable (DAC) =$437+$269+300 = $1,006 

  16GFC with SFP+ Optics = $773 + $405 + $1,400 = $2,578 

  So iSCSI is the lowest price if DAC cables are used. Note, in my example, I chose 3 meter cable length, but even if you choose shorter or longer cables (HPE supports from 0.65 to 7 meter cable lengths), this is still the lowest cost connection option. Surprisingly, the cost of the 10GbE optics makes the iSCSI solution with optical connections the most expensive configuration. When using fiber optic cables, the 16GFC configuration is lower cost. 

  So what are the trade-offs with DAC versus SFP+ options? It really comes down to distance and the number of connections required. The DAC cables can only span up to 7 meters or so. That means customers have only limited reach within or across racks. If customers have multiple racks or distance requirements of more than 7 meters, FC becomes the more attractive option, from a cost perspective. Also, DAC cables are bulky, and when trying to cable more than 10 ports or more, the cable bundles can become unwieldy to deal with. 

  On the performance side, let’s look at the differences. iSCSI adapters have impressive specifications of 10Gbps bandwidth and 1.5Million IOPS which offers very good performance. For FC, we have 16Gbps of bandwidth and 1.3Million IOPS. So FC has more bandwidth and iSCSI can deliver slightly more transactions. Well, that is, if you take the specifications at face value. If you dig a little deeper here’s some things we learn:

  • 16GFC delivers full line-rate performance for block storage data transfers. Today’s 10GbE iSCSI runs on the Ethernet protocol with Data Center Bridging (DCB) which makes this a lossless transmission protocol like FC. However the iSCSI commands are transferred via Transmission Control Protocol (TCP)/IP which add significant overhead to the headers of each packet. Because of this inefficiency, the actual bandwidth for iSCSI traffic is usually well below the stated line rate. This gives16GFC the clear advantage in terms of bandwidth performance.
  • iSCSI provides the best IOPS performance for block sizes below 2K. Figure 1 shows IOPS performance of Cavium iSCSI with hardware offload. Figure 2 shows IOPS performance of Cavium’s QLogic 16GFC adapter and you can see better IOPS performance for 4K and above, when compared to iSCSI.
  • Latency is an order of magnitude lower for FC compared to iSCSI. Latency of Brocade Gen 5 (16Gb) FC switching (using cut-through switch architecture) is in the 700 nanoseconds range and for 10GbE it is in the range of 5 to 50 microseconds. The impact of latency gets compounded with iSCSI should the user implement 10GBASE-T connections in the iSCSI adapters. This adds another significant hit to the latency equation for iSCSI.

  

  図 1:Cavium’s iSCSI Hardware Offload IOPS Performance  

  図 2:Cavium’s QLogic 16Gb FC IOPS performance 

  If we look at manageability, this is where things have probably changed the most. Keep in mind, Ethernet network management hasn’t really changed much. Network administrators create virtual LANs (vLANs) to separate network traffic and reduce congestion. These network administrators have a variety of tools and processes that allow them to monitor network traffic, run diagnostics and make changes on the fly when congestion starts to impact application performance. The same management approach applies to the iSCSI network and can be done by the same network administrators. 

  On the FC side, companies like Cavium and HPE have made significant improvements on the software side of things to simplify SAN deployment, orchestration and management. Technologies like fabric-assigned port worldwide name (FA-WWN) from Cavium and Brocade enable the SAN administrator to configure the SAN without having HBAs available and allow a failed server to be replaced without having to reconfigure the SAN fabric. Cavium and Brocade have also teamed up to improve the FC SAN diagnostics capability with Gen 5 (16Gb) Fibre Channel fabrics by implementing features such as Brocade ClearLink™ diagnostics, Fibre Chanel Ping (FC ping) and Fibre Channel traceroute (FC traceroute), link cable beacon (LCB) technology and more. HPE’s Smart SAN for HPE 3PAR provides the storage administrator the ability to zone the fabric and map the servers and LUNs to an HPE 3PAR StoreServ array from the HPE 3PAR StoreServ management console. 

  Another way to look at manageability is in the number of administrators on staff. In many enterprise environments, there are typically dozens of network administrators. In those same environments, there may be less than a handful of “SAN” administrators. Yes, there are lots of LAN connected devices that need to be managed and monitored, but so few for SAN connected devices. The point is it doesn’t take an army to manage a SAN with today’s FC management software from vendors like Brocade. 

  So what is the right answer between FC and iSCSI? Well, it depends. If application performance is the biggest criteria, it’s hard to beat the combination of bandwidth, IOPS and latency of the 16GFC SAN. If compatibility and commonality with existing infrastructures is a critical requirement, 10GbE iSCSI is a good option (assuming the 10GbE infrastructure exists in the first place). If security is a key concern, FC is the best choice. When is the last time you heard of a FC network being hacked into? And if cost is the key criteria, iSCSI with DAC or 10GBASE-T connection is a good choice, understanding the tradeoff in latency and bandwidth performance. 

  So in very general terms, FC is the best choice for enterprise customers who need high performance, mission-critical capability, high reliability and scalable shared storage connectivity. For smaller customers who are more cost sensitive, iSCSI is a great alternative. iSCSI is also a good protocol for pre-configure systems like hyper-converged storage solutions to provide simple connectivity to existing infrastructure. 

  As a wise manager once told me many years ago, “If you start with the customer and work backwards, you can’t go wrong.” So the real answer is understand what the customer needs and design the best solution to meet those needs based on the information above.

  続きを読む
• January 11, 2018

  

  

  

  自動車の車内ネットワークとその応用を大きく変えるイーサネット

  マーベル、オートモーティブ・アプリケーション＆アーキテクチャ担当シニアダイレクター、クリストファー・マッシュ著

  現在自動車で使われている車載ネットワークは、いくつかの異なるデータネットワーキングプロトコルの組み合わせに基づいており、そのうちのいくつかは何十年も前から使われている。 パワートレインと関連機能を担当するCAN（コントローラエリアネットワーク）、主に時間的制約のない乗員／ドライバーの快適性（空調制御、環境照明、シート調整など）に使用されるLIN（ローカルインターコネクトネットワーク）、インフォテインメント用に開発されたMOST（メディアオリエンテッドシステムトランスポート）、ABS（アンチロックブレーキ）、EPS（エレクトロニックパワーステアリング）、車両安定機能用のFlexRay™がある。 

  異なるプロトコルを使用する結果、インフラ内でのデータ転送にはゲートウェイが必要となる。 その複雑さゆえの結果、自動車メーカーにはコストがかかる。 また、それぞれのネットワークに必要なワイヤーハーネスが車両重量を増やすため、燃費にも影響する。 ワイヤーハーネスはエンジン、シャシーに次いで3番目に重く、3番目に高価な部品である。 さらに、これらのゲートウェイには待ち時間の問題があり、迅速な対応が求められるセーフティクリティカルなアプリケーションに影響を与える。 

  自動車に搭載される電子制御ユニット（ECU）の数は増加の一途をたどっており、高級車では150個以上、標準車でも80～90個に迫るECUが搭載されることもある。 同時に、より高度な車両自律性に向けて、先進運転支援システム（ADAS）の実装をサポートするデータ集約型アプリケーションも登場している。 このため、HDカメラやLiDAR技術の導入が進み、データレートと帯域幅全体が大幅に増加している。 

  その結果、車載ネットワーキングが展開される上で、第一に使用されるトポロジーの点で、第二にそれが依存する基本技術の点で、根本的に変わる必要がある。 

  現在、車内のネットワーキング・インフラはドメインベースのアーキテクチャである。 ボディコントロール、インフォテインメント、テレマティクス、パワートレインなど、主要機能ごとにドメインが分かれている。 これらのドメインでは、多くの場合、異なるネットワークプロトコルが混在している（例えば、CAN、LINなどが関係している）。 

  ネットワークが複雑化するにつれ、このドメインベースのアプローチが効率的でなくなってきていることは、自動車エンジニアにとって明らかだ。 その結果、今後数年間は、現在のドメインベースのアーキテクチャからゾーンベースのアーキテクチャへの移行が必要になるだろう。

   ゾーン配置とは、車両内のECUの位置（ゾーン）に基づいて、異なる従来のドメインからのデータが同じECUに接続されることを意味する。 この配置により、必要なワイヤーハーネスが大幅に削減され、それによって重量とコストが削減され、ひいては燃費の向上につながる。 イーサネット技術は、ゾーンベースの車載ネットワークへの移行において極めて重要な役割を果たす。 

  イーサネットテクノロジーがサポートする高速データレートに加え、イーサネットは世界的に認知されているOSI通信モデルに準拠している。 イーサネットは、データ通信や産業オートメーション分野ですでに広く導入されている、安定した、長い歴史を持ち、よく理解された技術である。 他の車載ネットワークプロトコルと異なり、イーサネットには、さらなるスピードグレードをターゲットとする明確な開発ロードマップがある。一方、CANやLINなどのプロトコルは、すでにアプリケーションがその能力を超え始めている段階に達しており、問題を軽減する明確なアップグレードの道はない。 

  将来的には、イーサネットが車内でのすべてのデータ転送の基盤となり、異なるプロトコル間のゲートウェイ（ハードウェアコストとそれに伴うソフトウェアのオーバーヘッド）の必要性を減らす共通のプロトコル・スタックを提供することが期待されている。 その結果、すべてのプロトコルとデータ形式が一貫した、車両全体で単一の均質なネットワークが実現する。 これは、車載ネットワークがスケーラブルであることを意味し、高速（たとえば10G）と超低遅延を必要とする機能に対応できるようにする一方で、低速機能のニーズにも対応できるようにする。 イーサネットPHYは、画像センシングデータを伝送するための1Gbpsデバイスであれ、自律走行に使用される新しいクラスの低データレートセンサーに必要な10Mbps動作のものであれ、特定のアプリケーションと帯域幅の要求に応じて選択される。 

  ゾーンアーキテクチャの各イーサネットスイッチは、すべての異なるドメインアクティビティのデータを伝送することができる。 すべての異なるデータドメインはローカルスイッチに接続され、イーサネットバックボーンがデータを集約し、その結果、利用可能なリソースをより効果的に使用できるようになり、同じコアプロトコルを使用しながら、必要に応じて異なる速度をサポートできるようになる。 この均質なネットワークは、車内で "どこにいても、どんなデータでも "提供し、ネットワークを通じて利用可能なさまざまな領域のデータを組み合わせることで、新しいアプリケーションをサポートする。 

  Marvell is leading the way when it comes to the progression of Ethernet-based, in-vehicle networking and zonal architectures by launching, back in the summer of 2017, the AEC-Q100-compliant 88Q5050 secure Gigabit Ethernet switch for use in automobiles. This device not only deals with OSI Layers 1-2 (the physical layer and data layer) functions associated with standard Ethernet implementations, it also has functions located at OSI Layers 3,4 and beyond (the network layer, transport layer and higher), such as deep packet inspection (DPI). This, in combination with Trusted Boot functionality, provides automotive network architects with key features vital in ensuring network security. 

  続きを読む

最新の記事

• HashiCorp and Marvell: Teaming Up for Multi-Cloud Security Management
• Cryptomathic and Marvell: Enhancing Crypto Agility for the Cloud
• The Big, Hidden Problem with Encryption and How to Solve It
• Self-Destructing Encryption Keys and Static and Dynamic Entropy in One Chip
• Dual Use IP: Shortening Government Development Cycles from Two Years to Six Months