在我们考虑大数据时,我们注意到了“大”这个字,但是在建设基础架构时,我们还应该注意“分布式”。事实上,大数据应用程序需要处理大规模信息,而且在出于弹性的考虑将数据复制到多个位置时,信息的规模变得越来越大。但是,大数据的最重要属性并不在于它的规模,而在于它将大作业分割成许多小作业的能力,它能够将处理一个任务的资源分散到多个位置变为并行处理。在将大规模和分布式架构组合在一起时,我们就能发现大数据网络有一组特殊的需求。下面是需要考虑的六个方面:
1.网络弹性与大数据应用程序
如果有一组分布式资源必须通过互联网络进行协调时,可用性就变得至关重要。如果网络出现故障,那么造成的后果是出现不连续的坏计算资源与数据集。
准确地说,大多数网络架构和工程师的主要关注点是正常运行时间。但是,网络故障时间的根源又各不相同。它们可能源自于各个方面,包括设备故障(硬件与软件)、维护和人为错误。故障是不可避免的。虽然网络的高度可用性也很重要,但是想要设计**可用性是不可能的。
网络架构师不能用故障来逃避目标,而应该设计一些能适应故障的弹性网络。网络的弹性取决于路径多样性(资源之间设置多条路径)和故障转移(能够快速发现问题和转移到其他路径上)。除了传统的平均故障时间间隔(MTBF)方法,大数据网络的真正设计标准一定要包含这些特性。
2.解决大数据应用中的网络拥塞问题
大数据应用程序不仅仅舒模大,而且还有一种我称为突发性的特性。当一个作业启动之后,数据就开始流转。在高流量时间段里,拥塞是一个严重的问题。然而,拥塞可能引起更多的队列延迟时间和丢包率。此外,拥塞还可能触发重转,这可能让本身负载繁重的网络无法承受。因此,网络架构设计时应该尽可能减少拥塞点。按照可用性的设计标准,减少拥塞要求网络具有较高的路径多样性,这样才能允许网络将流量分散到大量不同的路径上。
3.大数据中网络一致性要比迟延性更重要
实际上,大多数大数据应用程序对网络延迟并不敏感。如果计算时间的数量级为几秒钟或几分钟,那么即使网络上出现较大延迟也是无所谓的——数量级大概为几千毫秒。然而,大数据应用程序一般具有较高的同步性。这意味着作业是并行执行的,而各个作业之间较大的性能差异可能会引发应用程序的故障。因此,网络不仅要足够**,而且要在空间和时间上具有一致的性能。
4.现在就要准备大数据未来的可伸缩性
可能让人有点意外的是,大多数大数据集群实际上并不大。许多人都知道雅虎在其大数据环境中运行着超过42,000个节点,但是根据Hadoop Wizard的数据,2013年大数据集群的平均节点数量只有100个。换句话说,即使每一台服务器配置双重冗余,支持整个集群也只需要4个接入交换机(假设是分别有72个10GbE访问端口的Broadcom交换机)。
可伸缩性并不在于现在集群现在有多大规模,而是说如何平衡地扩展支持未来的部署规模。如果基础架构设计现在只适合小规模部署,那么这个架构将如何随着节点数量的增加而不断进化?在将来某一个时刻,它是否需要完全重新设计架构?这个架构是否需要一些近程数据和数据位置信息?关键是要记住,可伸缩性并不在于**规模,而是更关注于实现足够规模解决方案的路径。
5.通过网络分割来处理大数据
网络分割是创建大数据环境的重要条件。在最简单的形式上,分割可能意味着要将大数据流量与其他网络流量分离,这样应用程序产生的突发流量才不会影响其他关键任务工作负载。除此之外,我们还需要处理运行多个作业的多个租户,以满足性能、合规性和/或审计的要求。这些工作要求在一些场合中实现网络负载的逻辑分离,一些场合则还要实现它们的物理分离。架构师需要同时在两个方面上进行规划,但是初始需求**统一在一起。
6.大数据网络的应用感知能力
虽然大数据的概念与Hadoop部署关系密切,但是它已经成为集群环境的代名词。根据不同应用程序的特点,这些集群环境的需求各不同相同。有一些可能对对带宽要求高,而有一些则可能对延迟很敏感。总之,一个网络要支持多应用程序和多租户,它就必须要能够区分自己的工作负载,并且要能够正确处理各个工作负载。
大数据网络设计的关键是要理解一点:需求不仅仅是提供足够的东西向带宽。最终,应用程序体验取决于很多因素,包括网络拥塞和分割。创建一个满足所有这些需求的网络需要有前瞻性,不仅要考虑基础架构能够支持的伸缩规模,还要考虑不同类型的应用程序如何共存于一个通用环境 |