How To Optimize A Network For Big Data

Transcription

1 G Is Your Network Ready for Big Data? Published: 31 October 2013 Analyst(s): Andrew Lerner, Nick Heudecker Big data initiatives are increasing in number, scale and business criticality. However, clients must ensure their data center networks are optimized to handle big data's unique characteristics. This research identifies what network designers must do to meet requirements of big data initiatives. Impacts Increasing enterprise demand for big data solutions requires network designers to reassess existing network infrastructures to ensure optimized performance. Many organizations are utilizing public cloud services for big data solutions, and network designers must optimize network connectivity for these implementations. Recommendations Network designers should deploy big data nodes on high-performance network equipment to ensure appropriate levels of performance and capacity. Network designers should logically and physically segment big data services from the rest of the network environment to improve performance. Network and big data application teams should collaborate to understand projected workload, estimated data growth and required SLAs. Network designers must optimize connectivity for big data solutions deployed off-premises. Analysis Big Data Is Coming Big data is top-of-mind for many IT organizations today, and there is a large amount of interest surrounding this topic, as evidenced by:

2 A recent Gartner survey of 720 organizations indicated that 64% are investing or planning to invest in big data technology in Big data is one of the most-searched topics on gartner.com over the last 12 months (29,545 searches). This search volume is greater than searches for Cisco, Juniper, Firewall and HP combined (25,871), and on par with searches for data center (30,215). Over the past 12 months, client inquiries to Gartner relating to big data technologies have increased by 42%. Introducing Big Data to the Network Team Enterprises initiate big data projects to address a range of business problems. The primary use cases to date have been enhancing customer experience and/or improving process efficiency (see "Survey Analysis: Big Data Adoption in 2013 Shows Substance Behind the Hype" and Note 1). Deriving value from big data initiatives involves dealing with multiple sources of data with varying levels of structure and relationships. Different technologies must be combined when multiple outcomes are desired, such as offline batch analytics, real-time data processing and interactive data exploration. Big Data Components The most common big data components and vendor solutions include: Hadoop is a popular open-source Apache Hadoop framework that commonly fulfills batch analysis use cases. Commercial support for Hadoop is provided by several vendors, including Cloudera, Hortonworks, Pivotal, and MapR, among others. Hadoop provides distributed storage and a method to process stored data in parallel, but its batch nature makes it unsuitable for real-time use cases. In-memory technologies are commonly used to support interactive data exploration tasks. These technologies include in-memory databases and data grids, such as those provided by ScaleOut Software and GridGain. Complex-event processing (CEP) and distributed stream computing platforms (DSCPs) fulfill real-time scenarios by processing data in motion and informing downstream consumers that an event occurred or some action is required. IBM InfoSphere Streams, SQLstream and Software AG's Apama each provide some level of support for CEP and DSCP capabilities. Page 2 of 14 Gartner, Inc. G

3 Figure 1. Big Data Components and Time Horizons Response Time Frames < 30 ms > 30 ms and < 10 min > 10 min Source Data Real-Time Monitoring and Analytics CEP and DSCP Interactive Analytics and Exploration In-Memory Technologies Batch Analytics Hadoop Source: Gartner (October 2013) Big Data Infrastructure Characteristics Big data infrastructure can be deployed on-premises or off-premises, and for off-premises it is typically installed in public clouds or hosting facilities. As a result, the networking requirements for an enterprise vary dramatically based on location of installation. However, within an organization's data center, the prevailing characteristics of big data servers include: High-bandwidth and extremely bursty traffic patterns. Low-cost, rack-mount (i.e., nonblade) commodity servers, deployed in a scale-out fashion. Utilization localized disk versus storage area networks (SANs), and as a result, data is not typically replicated to other data centers (see Note 2) Big Data: The Opposite of Virtualization Over the past several years, virtualization and cloud computing have drastically impacted data center infrastructures, leading to new networking architectures. However, on-premises big data solutions are not typically virtualized and essentially have the opposite impact of virtualization: A big data workload (i.e., Hadoop) is typically spread across several physical servers, versus multiple workloads consolidated to one physical server. Gartner, Inc. G Page 3 of 14

4 Figure 2. Virtualized Workloads Workload Workload Workload VM VM VM Hypervisor Physical Server Source: Gartner (October 2013) Figure 3. Big Data (Hadoop) Workload Workload Physical Server Physical Server Physical Server Source: Gartner (October 2013) Page 4 of 14 Gartner, Inc. G

5 Figure 4. Impacts and Top Recommendations for Big Data Impacts Top Recommendations Increasing demand for big data solutions requires network designers reassess existing network infrastructures to ensure appropriate performance. Deploy big data nodes on highperformance network equipment. Segment big data infrastructure from the rest of your network environment. Many organizations are utilizing public cloud services for big data solutions, and network designers must optimize network connectivity for these implementations. Modify WAN architectures to limit or mitigate the performance impact of network latency. Source: Gartner (October 2013) Impacts and Recommendations Increasing enterprise demand for big data solutions requires network designers to reassess existing network infrastructures to ensure optimized performance Cross-Functional Collaboration Is Key The nature of big data projects requires several teams that may not typically collaborate to work together to provide the appropriate solution. The team should focus on how the information is consumed and used, which will in turn drive architecture and SLAs. The core considerations around big data's impact on the network infrastructure include: Variety of sources and rate of consumption Response time for different use cases Changing workloads Data Sources and Data Velocity Data can be consumed from several sources, as well as at different rates. For example, a big data project may include continuous streams of sensor or machine data, daily batches of transactions, as well as log data from a variety of sources. Each of these sources has different SLAs around throughput, latency and resiliency requirements. Understanding how the data is generated and sourced allows network planners to properly scope project architecture. Gartner, Inc. G Page 5 of 14

6 Delivering Timely Results Higher-priority use cases, like those normally addressed by real-time components, require low response time capabilities and robust high availability/disaster recovery (HA/DR) solutions. On the other hand, batch use cases can tolerate higher latency and architectures typically have some builtin HA/DR capabilities (see "Hadoop and MapReduce: Big Data Analytics"). Interactive use cases, commonly supported by in-memory technologies, are the most difficult to scope. They require high bandwidth to move information from some type of repository into the in-memory store, as well as low latency to ensure the data is moved quickly. These challenges are impacted by the unpredictable nature of how interactive systems are used. They may be highly leveraged during a few weeks per year, or heavily used throughout the year by a set of power users, based on business processes. Auditing how interactive systems will be used allows you to optimize for performance while meeting business objectives. Ensuring a consistent experience to users of interactive systems can help reinforce the perceived value of a big data project (see "Focus on Five Dimensions of Design to Improve Performance and Save Money"). Adapt to Changing Data Characteristics Finally, big data solutions must be scoped in the context of how data volumes, variety and velocity will change over time. The key consideration is not necessarily volume, but the increasing variety and velocity of data driven by the proliferation of sensors, devices and communication streams. This sensor and machine data, what Gartner broadly considers the Internet of Things (IoT), is likely to become the dominant form of data under management. As part of this shift, investment in analytical tools, storage and network infrastructure must adapt to new business priorities driven by the IoT. Deploy Big Data Nodes on High-Performance Networking Equipment Big data servers generate intense networking requirements, heavy volume and bursty server-toserver (i.e., east/west) traffic. To address these characteristics, network designers must ensure their network switching infrastructure meets key requirements (see Table 1). Table 1. Big Data Switching Requirements Characteristic Switching Requirement High volume of traffic between servers High-bandwidth access and uplink interfaces Bursty traffic patterns and varying data collection patterns Lower latency Line-rate capability with low oversubscription ratios Deep packet buffering capability Lower latency Source: Gartner (October 2013) Page 6 of 14 Gartner, Inc. G

7 Data Center Network Fabrics Organizations that have already implemented a modern "Ethernet Fabric" (i.e., a one- or two-tier physical mesh or partial mesh topology) will likely meet the above networking requirements (see "Technology Overview for Ethernet Switching Fabric"). Ethernet fabric examples include Avaya's Vena, Brocade's VCS, Cisco System's FabricPath and Juniper's QFabric. However, we recommend that clients restrict big data nodes to a limited subset of overall switches within the fabric to limit collateral impact to other services running in the environment. Adoption of Ethernet fabrics has been low, as only approximately 10% of mainstream enterprises have implemented them in their environments. 2 In addition, these implementations are typically reserved for greenfield data center build-outs. 3 Thus, many organizations will need to deploy big data solutions within traditional data center network architectures. Traditional Data Center Network Architectures For organizations that operate three or more tiers in their data center networks, we recommend a build-out of separate physical infrastructure using dedicated switches in one- or two-tier physical configurations (connecting directly to the existing core network). Top-of-rack (ToR) switches providing 10G server access are available from multiple networking vendors, and a resilient solution supporting 40+ big data servers has a three-year hardware/ maintenance cost ranging from $25,000 to $50, In addition, since these new switches are segmented and service specific use cases, this provides an opportunity to pilot non-incumbent solutions and configurations in your environment (see "Rightsizing the Data Center Network"). Line-Rate, Low Oversubscription and High-Bandwidth Interfaces Network designers should use fixed format switches with 10G interfaces to provide the higher bandwidth required by big data nodes. In addition, 10G switches provide lower latency than 1G switches and are recommended by several big data vendors for optimal performance (i.e., inmemory database SAP Hana 5 ). Switches that support big data nodes should be line-rate (i.e., the backplane capacity of the switch should equal the full-duplex speed of all server-facing interfaces). In addition, network designers should prefer switches that offer low oversubscription rates (see Note 3), ideally 3:1 or lower. Also, if multiple switches are required for redundancy, network designers should cross-connect them to each other to avoid traffic having to traverse an upstream device. Deep Packet Buffers Big data requires switches with larger interface buffering capability to improve performance during bursts of traffic. Buffering varies significantly across vendor platforms, ranging from several hundred KBs to a MB and can be both fixed (per port or grouping of ports) or dynamic. Network designers should prefer solutions that support at least 1MB of buffering per port. Gartner, Inc. G Page 7 of 14

8 Latency: Microseconds Matter but "Ultralow" Latency Is Not Required Switch latency is best measured as a port-to-port intraswitch measure and varies significantly across vendor and product lines, ranging from 0.2 to 3.3 microseconds on modern switches that provide 10G server access. 6 Switches limited to 1G access speeds typically have higher latency, ranging from 4 to 10 microseconds. 7 When evaluating latency solutions from networking vendors, organizations should take the following into account: Several vendors offer ultralow-latency switches 8 primarily aimed at high-performance computing and high-frequency financial trading. While no official definition of "ultralow" latency exists, it is typically referred to as intraswitch port-to-port latency in the range of one microsecond or below. Ultralow-latency switches can improve big data performance but are not typically required to provide adequate big data performance. For big data, we recommend clients use solutions that provide local switching capability, which limits bandwidth utilization on uplink interfaces and reduces intraswitch latency. Cabling and server network interface cards (NICs) also have a significant impact on latency. For example, copper 10GBase-T latency is typically in the 2- to 2.5-microseconds range, versus small form-factor pluggable (SFP) solutions that are usually less than 0.5 microseconds. Thus, we recommend using SFP. Table 2. Summary of Big Data Switching Requirements Typical Data Center Ethernet Switch Ranges Line-rate is common for most data center switches. Server-facing interfaces range from 10/100/1,000 Mbps to 40 Gbps Uplink interfaces range from 1GB to 100GB Oversubscription on uplink typically ranges from 12:1 to 1:1 Intraswitch latency ranges from 0.19 to 10 microseconds Per-port buffers range significantly, typically from several hundred kilobytes (static) to several megabytes (dynamic) Recommendations for Big Data Switches Line-rate should be a requirement 10GB interfaces should be utilized for interfaces that connect to big data nodes. Prefer uplink interfaces that are 40GB or higher. Prefer lower subscription rates, ideally 3:1 or better. Prefer lower latency, less than 4 microseconds, ideally closer to 1 microsecond Prefer higher buffers, ideally at least 1 megabyte per port. Source: Gartner (October 2013) Page 8 of 14 Gartner, Inc. G

9 Logically and Physically Segment Big Data Services Physical Separation We recommend physically aggregating big data servers to a limited number of network switches (preferably as few as possible, while maintaining redundancy). This will optimize latency and bandwidth utilization between big data nodes and simultaneously prevent degradation of other services installed on adjacent devices/ports. In addition to improving performance, reducing the number of devices involved improves the overall system mean time between failures (MTBF), as there are fewer components. However, in this configuration, the failure of a single switch has a greater impact on big data, but can be mitigated by following these practices: Cable big data physical server NICs to diverse switches (i.e., dual-home). Utilize switches with redundant power supplies. Utilize multiple uplink and inter-connection interfaces on switches that connect to big data servers Connect big data switches directly to the network core, bypassing aggregation or distribution tiers. Avoid traditional spanning-tree flavors in favor of protocols that recover from outages in a rapid manner (i.e., Trill, SPB, ECMP, etc.). Logical Separation In addition to physical segmentation, organizations should deploy big data servers on dedicated logical network segments i.e., virtual LANs (VLANs). This logical separation enables specialized handling of big data traffic, providing three specific advantages: This allows for specialized traffic engineering and handling (i.e., routing) for big data traffic. This allows for specific policies to be applied such as security settings and data loss prevention. This reduces the collateral impact (i.e., resource starvation) of adjacent traffic within the data center. In addition, network designers should deploy higher-layer L4 to L7 network services at the edge of the big data zone, not within it. This includes firewall/acl, IDS/IPS, and DLP, etc. This will allow the traffic to be appropriately serviced while ingressing and egressing the big data zone but will not slow performance within it. Recommendations: Network and big data application teams should collaborate to understand projected workload, estimated data growth and required SLAs. Gartner, Inc. G Page 9 of 14

10 Network designers should deploy big data nodes on high-performance networking equipment to ensure appropriate levels of performance and capacity. Network designers should logically and physically segment big data services from the rest of the network environment to improve performance. Many organizations are utilizing public cloud services for big data solutions, and network designers must optimize network connectivity for these implementations Organizations can deploy big data solutions either on-premises or off-premises, which will be driven by their specific preferences, use cases and requirements. Some organizations prefer on-premises deployments for the physical control and security while others deploy in hosting providers or public clouds to maximize agility and capacity provided. In some instances, the volume associated with data feeds will dictate placement of the cluster. For example, to optimize bandwidth expenditure and latency, a big data solution that requires consumption of several high-bandwidth inputs (i.e., social networking feeds) should be deployed in a carrier-neutral colocation facility. There are several considerations network personnel must consider when deploying big data in offpremises infrastructure. Since cloud providers own and operate their internal physical network infrastructure, enterprises have almost no control over the internal workings of it. For this reason, organizations should evaluate cloud provider SLAs regarding (1) end-to-end response time and (2) internal latency within the cloud provider's network when evaluating cloud server offerings, ideally as part of an RFP. In some cases, basic Internet connectivity to the cloud provider will provide "good enough" performance. However, as big data becomes more critical to the business it is likely that organizations will need to improve performance for these services. Network designers should minimize or mitigate the latency between their organization and cloud provider. Specific options to improve latency include reducing the geographic distance to your cloud provider or using WAN optimization technologies. Minimizing Latency via Reducing Geographic Distance Latency can be reduced via modifying network architectures to limit the physical distance between your organization and the cloud provider's network (see "Optimize Enterprise Networks to Improve SaaS Performance"). Specific options to reduce latency include adding the cloud provider to an existing WAN service, procuring dedicated circuits to the cloud provider, or using a data center colocation provider. Leveraging Existing WAN Services A relatively simple option is to procure connectivity to the cloud provider via your existing WAN service, typically MPLS. Several MPLS carriers simultaneously operate IaaS clouds and provide direct connectivity between these offerings. In addition, partnerships have emerged between several MPLS and cloud providers including Sprint/CSC, AT&T/Microsoft, and others. Cost varies significantly (depending primarily on bandwidth), but this is typically the least expensive approach. Page 10 of 14 Gartner, Inc. G

11 Dedicated Circuits Another option is to procure dedicated circuits (typically optical or Ethernet) that terminate directly in the cloud provider's data center. However, not all cloud providers support dedicated circuits from customers, so in many instances, you will be limited by what the cloud provider supports. When procuring these services, ensure there are specific SLAs included in the contract regarding maximum latency. Cost varies significantly (depending primarily on bandwidth and distance), but this is generally more expensive than MPLS. Data Center Colocation Services Organizations can also use a data center colocation facility provider for connectivity to cloud providers. In this approach, you connect to a colocation data center facility (either via a dedicated connection or via an existing WAN service) where the cloud provider is already connected. In essence, the colocation provider is used as a routing exchange between the organization and the desired cloud provider. This method gained mainstream popularity by Amazon Web Services through partnerships with colocation providers Equinix, Coresite and others. In addition, direct partnerships have emerged between MPLS carriers and colocation providers, including Equinix and Verizon. This often provides the lowest latency and consequently best performance, but is also typically the most expensive. Mitigating Latency via WAN Optimization The other option to improve performance is to mitigate latency. Nearly all major IaaS providers support WAN optimization controller instances in their service catalogs (e.g., Riverbed, Citrix and Silver Peak WOC instances are all available via Amazon Web Services). These WOC virtual appliances can be peered with organizations' on-premises WOC solutions and typically reduce latency significantly (i.e., 30% to 70%) as well as reduce bandwidth (35% to 70%). This results in significantly improved application performance (see "Magic Quadrant for Wan Optimization Controllers"). Recommendation: Network designers must optimize connectivity for big data solutions deployed off-premises. Gartner Recommended Reading Some documents may not be available as part of your current Gartner subscription. "Hype Cycle for Big Data, 2013" "Best Practices for Deploying Hadoop in Amazon Web Services" "Technology Overview for Ethernet Switching Fabric" "Toolkit: Sample RFP for Data Center Network" Gartner, Inc. G Page 11 of 14

12 "Key Considerations for Deploying Hadoop in a Public Cloud" Evidence The information included in this research is derived from briefings, white papers, presentations and technical specification sheets from leading networking vendors, including Alcatel-Lucent, Arista, Avaya, Brocade, Cisco, Dell, Enterasys, Extreme, HP, Huawei, Juniper and Mellanox. The information included in this research is derived from briefings and review of MPLS and data center colocation provider service offerings. 1 Gartner Survey Reveals That 64 Percent of Organizations Have Invested or Plan to Invest in Big Data in This is based on review of reported vendor shipments and over 1,500 client interactions regarding networking over the past 12 months. 3 This is based on over 1,500 client interactions regarding networking over the past 12 months. 4 This is based on hardware, software and three-year maintenance and assumes each big data node is dual connected to redundant switches. 5 Prepare the Data Center 6 This is based on switch offerings from Cisco Systems, HP, Dell, Arista, Brocade, Avaya and Juniper. Cisco's Nexus 3000 series switch provides the lowest Ethernet switch latency in the market today at 190 nanoseconds. 7 This is based on switch offerings from Cisco Systems, HP and Juniper. 8 Examples include Cisco Nexus 3000, Arista 7100, HP 5900 and Dell S5000. Note 1 Examples of a Big Data Implementation To better understand and serve online customers, Walmart combined clickstream data with product and category popularity scores to provide individual product suggestions. Completed transactions increased between 10% and 15% (see "Walmart Builds its own Shopping Search Engine," Gigaom, August 2013). A manufacturing company analyzed sales, manufacturing and inventory data to identify patterns of configurations commonly bought by customers. It was able to identify a set of base configurations and correlate those with customer demand. This resulted in a 61% reduction in product variety, leading to a 25% increase in manufacturing productivity. In addition, inventory days were reduced by 81%, while maintaining service levels. Additional big data use cases and possibilities can be found in the "Toolkit: Big Data Business Opportunities From Over 100 Use Cases." Page 12 of 14 Gartner, Inc. G

13 Note 2 Big Data Replication Although replication and cross-data-center failover are not natively supported within Apache Hadoop, big data solutions that require cross-data-center replication can utilize commercial software solutions from vendors such as WANdisco. Note 3 Oversubscription This is defined as the server-facing bandwidth divided by the uplink bandwidth (for example, a 48- port 10G switch with 4 x 40G uplinks would be 480:160, or 3:1). Gartner, Inc. G Page 13 of 14

14 GARTNER HEADQUARTERS Corporate Headquarters 56 Top Gallant Road Stamford, CT USA Regional Headquarters AUSTRALIA BRAZIL JAPAN UNITED KINGDOM For a complete list of worldwide locations, visit Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. or its affiliates. This publication may not be reproduced or distributed in any form without Gartner s prior written permission. If you are authorized to access this publication, your use of it is subject to the Usage Guidelines for Gartner Services posted on gartner.com. The information contained in this publication has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information and shall have no liability for errors, omissions or inadequacies in such information. This publication consists of the opinions of Gartner s research organization and should not be construed as statements of fact. The opinions expressed herein are subject to change without notice. Although Gartner research may include a discussion of related legal issues, Gartner does not provide legal advice or services and its research should not be construed or used as such. Gartner is a public company, and its shareholders may include firms and funds that have financial interests in entities covered in Gartner research. Gartner s Board of Directors may include senior managers of these firms or funds. Gartner research is produced independently by its research organization without input or influence from these firms, funds or their managers. For further information on the independence and integrity of Gartner research, see Guiding Principles on Independence and Objectivity. Page 14 of 14 Gartner, Inc. G