没有合适的资源?快使用搜索试试~ 我知道了~
### Google B4网络架构知识点详解
#### 一、引言
现代广域网(WAN)对于互联网性能和可靠性至关重要,能够提供每秒数千兆比特的聚合带宽跨数千条独立链路。传统WAN路由器通常由高端且专门设计的设备构成,这些设备对高可用性有极高的要求。此外,WAN一般会平等对待所有数据包,虽然这种做法有许多好处,但在出现故障时,所有应用程序都会受到同等的影响,无论它们对可用容量的敏感度如何。
鉴于上述考虑,WAN链路通常被配置为平均利用率在30%-40%之间。这样做可以让网络服务提供商几乎屏蔽所有的链路或路由器故障对客户端的影响。然而,这种保守的设计也导致了资源的浪费。在这种背景下,Google设计并实施了一种名为B4的新一代广域网架构,旨在实现更高效的带宽利用和流量管理。
#### 二、B4的主要特性
**1. 大规模带宽需求**
B4旨在连接全球范围内的Google数据中心,因此其设计之初就考虑到了巨大的带宽需求。这一特性要求B4具备能够承载极高数据传输速率的能力。
**2. 弹性流量需求**
B4的设计考虑到了流量需求的变化性和不可预测性,系统能够根据应用的实际需求动态调整带宽分配,以最大化整体带宽利用率。
**3. 对边缘服务器和网络的完全控制**
由于Google对其数据中心和网络基础设施拥有完全的控制权,这使得B4能够实施更精细的流量管理和监控机制,如速率限制和需求测量等。
**4. 软件定义网络(SDN)架构**
B4采用了OpenFlow协议来构建一个集中式的流量工程服务,通过这种方式可以控制基于商用芯片制造的相对简单的交换机。这种设计使得B4能够实现高度自动化和灵活的网络管理。
#### 三、B4的核心组件和技术
**1. 集中式流量工程服务**
B4的流量工程服务是整个系统的核心。该服务能够动态地将应用程序的数据流分配到不同的路径上,以平衡网络容量与应用程序优先级/需求之间的关系。通过这种方式,即使在网络拥塞或故障情况下也能确保关键应用程序的正常运行。
**2. OpenFlow与软件定义网络**
B4利用OpenFlow协议实现了软件定义网络(SDN),这是一种新型的网络架构模式,允许网络管理员以程序化的方式控制网络行为。B4通过OpenFlow协议实现了对网络流量的精细化控制,从而提高了网络资源的利用率。
**3. 商用硅基交换机**
为了降低成本并简化部署过程,B4采用了基于商用硅基芯片的交换机。这些交换机虽然功能相对简单,但通过集中式控制器的智能调度,能够高效地处理大规模的网络流量。
#### 四、实践经验与未来工作方向
**1. 实践经验**
自2011年以来,B4已经在Google生产环境中稳定运行了三年。在这段时间里,Google积累了丰富的实践经验,并不断优化和完善B4的设计。例如,通过持续改进集中式流量工程服务算法,B4成功地将链路利用率提升至接近100%,极大地提高了带宽的使用效率。
**2. 未来工作方向**
尽管B4已经取得了显著的成功,但Google仍然面临着许多挑战,包括但不限于:
- 如何进一步提高网络的可扩展性和灵活性。
- 如何应对日益增长的流量需求。
- 如何更好地集成新兴的技术和服务,如5G和物联网。
Google的B4网络架构通过一系列创新性的设计和技术实现,不仅满足了Google全球数据中心间的大规模带宽需求,还为未来的网络发展提供了宝贵的参考案例。随着技术的不断进步和应用场景的多样化,B4及其背后的原理将继续发挥重要作用。
B4: Experience with a Globally-Deployed
Software Defined WAN
Sushant Jain, Alok Kumar, Subhasree Mandal, Joon Ong, Leon Poutievski, Arjun Singh,
Subbaiah Venkata, Jim Wanderer, Junlan Zhou, Min Zhu, Jonathan Zolla,
Urs Hölzle, Stephen Stuart and Amin Vahdat
Google, Inc.
b4-sigcomm@google.com
ABSTRACT
We present the design, implementation, and evaluation of B4, a pri-
vate WAN connecting Goog le’s data centers across the planet. B4
has a number of unique characteristics: i) massive bandwidth re-
quirements deployed to a modest number of sites, ii) elastic t raf-
c demand that seeks to maximize average bandwidth, and iii) full
control over the edge servers and network, which enables rate limit-
ing and demand measurement at the edge. ese characteristics led
to a Soware Dened Networking architecture using OpenFlow to
control relatively simple switches built from merchant silicon. B4’s
centralized trac engineering service drives links to near 100% uti-
lization, while splitting application ows among multiple paths to
balance capacity against application priority/demands. We describe
experience with three years of B4 production deployment, lessons
learned, and areas for future work.
Categories and Subject Descriptors
C.2.2 [Network Protocols]: Routing Protocols
Keywords
Centralized Trac Engineering; Wide-Area Networks; Soware-
Dened Networking; Routing; OpenFlow
1. INTRODUCTION
Modern wide area networks (WANs) are critical to Internet per-
formance and reliability, delivering terabits/sec of aggregate band-
width across thousands of individual links. Bec ause individual
WAN links are expensive and because WAN packet loss is typically
thought unacceptable, WAN routers consist of high-end, specialized
equipment that place a premium on high availability. Final ly, WANs
typically treat all bits the same. While this has many benets, w hen
the inev itable failure does take place, all applications are t ypical ly
treated equally, despite their highly variable sensitivity to available
capacity.
Given these considerations, WAN links are typically provisioned
to 30-40% average utilization. is allows the network serv ice
prov ider to mask virtually all link or router failures from clients.
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full cita-
tion on the first page. Copyrights for components of this work owned by others than
ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or re-
publish, to post on servers or to redistribute to lists, requires prior specific permission
and/or a fee. Request permissions from permissions@acm.org.
SIGCOMM’13, August 12–16, 2013, Hong Kong, China.
Copyright 2013 ACM 978-1-4503-2056-6/13/08 ...$15.00.
Such overprovisioning delivers admirable reliability at the very real
costs of 2-3x bandwidth over-provisioning and high-end routing
gear.
We were faced with these overheads for building a WAN connect-
ing multiple data centers with substantial bandwidth requirements.
However, Google’s data center WAN exhibits a number of unique
characteristics. First, we control t he applications, servers, and the
LANs all the way to the edge of the network. Second, our most
bandwidth-intensive applications perform large-scale data copies
from one site to another. ese applications benet most from high
levels of average bandwidth and can adapt their transmission rate
based on available capacity. ey could similarly defer to higher pri-
ority interactive applications during periods of failure or resource
constraint. ird, we anticipated no more than a few dozen data
center deployments, making central control of bandwidth feasible.
We exploited these properties to adopt a soware dened net-
working (SDN) architecture for our d ata center WAN interconnect.
We were most motivated by deploying routing and t rac engineer-
ing protocols customized to our unique requirements. Our de-
sign centers around: i) accepting failures as inevitable and com-
mon events, whose eects should be exposed to end applications,
and ii) switch hardware that exports a simple interface to program
forwarding table entries under central control. Network protocols
could then run on s ervers housing a variety of standard and custom
protocols. Our hope was that deploying novel routing, scheduling ,
monitoring, and management functionality and protocols would be
both simpler and result in a more ecient network.
We present our experience deploying Goog le’s WAN, B4, using
Soware Dened Networking (SDN) principles and OpenFlow [31]
to manage individual switches. In particular, we discuss how we
simultaneously support standard routing protocols and centralized
Trac Engineering (TE) as our rst SDN application. With TE, we:
i) leverage control at our network edge to adjudicate among compet-
ing demands during resource constraint, ii) use multipath forward-
ing/tunneling to leverage available network capacity according to
application priority, and iii) dynamically reallo cate bandwidth in the
face of link/switch failures or shiing application demands. ese
features allow many B4 links to run at near 100% utilization and all
links to average 70% utilization over long time periods, correspond-
ing to 2-3x eciency improvements relative to standard practice.
B4 has been in deployment for three years, now carries more traf-
c than Google’s public facing WAN, and has a hig her growth rate.
It is among the rst and largest SDN/OpenFlow deployments. B4
scales to meet application bandwidth demands more eciently than
would otherwise be possible, supports rapid deployment and iter-
ation of novel control functionality such as TE, and enables tig ht
integration with end applications for adaptive behavior in response
to failures or changing communicat ion patterns. SDN is of course
Figure 1: B4 worldwide deployment (2011).
not a panacea; we summarize our experience with a large-scale B4
outage, pointing to challenges in both SDN and large-scale network
management. While our approach does not generalize to all WANs
or SDNs, we hope that our experience will inform future design in
both domains.
2. BACKGROUND
Before describing the architecture of our soware-dened WAN,
we provide an overview of our deployment environment and tar-
get applications. G oogle’s WAN is among the largest in the Internet,
delivering a range of search, video, cloud computing, and enterprise
applications to users across the planet. ese services run across a
combination of data centers spread across the world, and edge de-
ployments for cacheable content.
Architecturally, we operate two distinct WANs. Our user-facing
network peers with and exchanges trac with other Internet do-
mains. End user requests and responses are delivered to our data
centers and edge caches across this network. e second network,
B4, provides connectivity among data centers (see Fig. 1), e.g., for
asynchronous data copies, index pushes for interactive serving sys-
tems, and end user data replication for availability. Well over 90%
of internal application trac runs across this network.
We maintain two separate networks because they have dierent
requirements. For example, our user-facing networking connects
with a range of gear and providers, and hence must support a wide
range of protocols. Further, its physical topology will necessarily be
more dense than a network connecting a modest number of data
centers. Finally, in delivering content to end users, it must support
the highest levels of availability.
ousands of individual applications run across B4; here, we cat-
egorize them into three classes: i) user data copies (e.g., email, doc-
uments, audio/video les) to remote data centers for availability/-
durability, ii) remote storage access for computation over inherently
distributed data sources, and iii) large-scale data push synchroniz-
ing state across multiple data centers. ese three trac classes are
ordered in increasing volume, decreasing latency sensitivity, and de-
creasing overall priority. For example, user-data represents the low-
est volume on B4, is the most latency sensitive, and is of the highest
priority.
e scale of our network deployment strains both the capacity
of commodity network hardware and the scalability, fault tolerance,
and granularity of control available from network soware. Internet
bandwidth as a whole continues to grow rapidly [25]. However, our
own WAN trac has b een growing at an even faster rate.
Our decision to build B4 around Soware Dened Networking
and OpenFlow [31] was driven by the observation that we could not
achieve the le vel of scale, fault tolerance, cost eciency, and control
required for our network using traditional WAN architectures. A
number of B4’s characteristics led to our design approach:
● Elastic bandwidth demands: e majority of our data cen-
ter trac involves synchronizing large data sets across sites.
ese applications b enet from as much bandwidth as they
can get but can tolerate periodic failures with temporary
bandwidth reductions.
● Moderate number of sites: While B4 must scale among multi-
ple dimensions, targeting our data center deployments me ant
that the total number of WAN sites would be a few dozen.
● End application control: We control both the applications and
the site networks connected to B4. Hence, we can enforce rel-
ative application priorities and control bursts at the network
edge, rather than through overprovisioning or complex func-
tionality in B4.
● Cost sensitivity: B4’s capacity targets and growth rate led to
unsustainable cost projections. e traditional approach of
prov isioning WAN links at 30-40% (or 2-3x the cost of a fully-
utilized WAN) to protect against failures and packet loss,
combined with prevailing per-port router cost, would make
our network prohibitively expensive.
ese considerations led to particular design decisions for B4,
which we summarize in Table 1. In particular, SDN gives us a
dedicated, soware-based cont rol plane running on commodity
servers, and the opportunity to reason about globa l state, yielding
vastly simplied coordination and orchestration for b oth planned
and unplanned network changes. SDN also allows us to leverage
the raw speed of commodity s ervers; latest-generation servers are
much faster than the embedded-class processor in most switches,
and we can upgrade servers independently from the switch hard-
ware. OpenFlow gives us an early investment in an SDN ecosys-
tem that can leverage a variety of switch/data plane elements. Crit-
ically, SDN/OpenFlow decouples soware and hardware evolution:
control plane soware becomes simpler and evolves more quickly;
data plane hardware evolves based on programmability and perfor-
mance.
We had several additional motivations for our soware dened
architecture, including: i) rapid iteration on novel protocols, ii) sim-
plied testing environments (e.g., we emulate our entire soware
stack running across the WAN in a local cluster), iii) improved
capacity planning available from simulating a deterministic cen-
tral TE ser ver rather than trying to capture the asynchronous rout-
ing behavior of distributed protocols, and iv) simplied manage-
ment through a fabric-centric rather than router-centric WAN view.
However, we leave a description of thes e aspects to separate work.
3. DESIGN
In this section, we describe the details of our Soware Dened
WAN architecture.
3.1 Overview
Our SDN architecture can be logically viewed in three layers, de-
picted in Fig. 2. B4 serves multiple WAN sites, each with a num-
ber of server clusters. Within each B4 site, the switch hardware
layer primarily forwards trac and does not run complex control
soware, and the site controller layer consists of Network Control
Servers (NCS) hosting both OpenFlow controllers (OFC) and Net-
work Control Applications (NCAs).
ese servers enable distributed routing and central trac engi-
neering as a routing overlay. OFCs maintain network state bas ed on
NCA directives and switch e vents and instruct switches to set for-
warding table entries based on this changing network state. For fault
tolerance of individual servers and control processes, a per-site in-
剩余11页未读,继续阅读
资源推荐
资源评论
2016-11-21 上传
5星 · 资源好评率100%
2013-02-23 上传
2021-09-29 上传
2024-05-14 上传
134 浏览量
2021-05-12 上传
119 浏览量
171 浏览量
186 浏览量
171 浏览量
111 浏览量
2021-10-25 上传
120 浏览量
178 浏览量
5星 · 资源好评率100%
109 浏览量
5星 · 资源好评率100%
5星 · 资源好评率100%
5星 · 资源好评率100%
183 浏览量
资源评论
xu23heng
- 粉丝: 0
- 资源: 3
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
- lanchaoHunanHoutaiQiantai
- (177377030)Python 爬虫.zip
- (177537818)python爬虫基础知识及爬虫实例.zip
- 自动驾驶横纵向耦合控制-复现Apollo横纵向控制 基于动力学误差模型,使用mpc算法,一个控制器同时控制横向和纵向,实现横纵向耦合控制 matlab与simulink联合仿真,纵向控制已经做好油门刹
- (178199432)C++实现STL容器之List
- (178112810)基于ssm+vue餐厅点餐系统.zip
- 两相步进电机FOC矢量控制Simulink仿真模型 1.采用针对两相步进电机的SVPWM控制算法,实现FOC矢量控制,DQ轴解耦控制~ 2.转速电流双闭环控制,电流环采用PI控制,转速环分别采用PI和
- VMware虚拟机USB驱动
- Halcon手眼标定简介(1)
- (175128050)c&c++课程设计-图书管理系统
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功