我们如何在莫斯科办公室的华为上设计和实现新网络,第1部分

图片

今天,我将讨论为公司创建新内部网络的想法是如何出现和实现的。 管理职位-您需要自己完成与客户相同的成熟项目。 如果我们为自己做好,我们将能够邀请客户并展示如何为客户提供满意的服务。 因此,我们在整个生产周期中非常彻底地着手开发了莫斯科办事处新网络的概念:分析部门的需求→选择技术解决方案→设计→实施→测试。 所以我们开始。

技术解决方案的选择:突变体的储备


迄今为止,在GOST 34.601-90“自动化系统”中对使用复杂的自动化系统进行操作的过程进行了最佳描述。 创作阶段”,因此我们进行了努力。 在形成需求和开发概念的阶段,我们遇到了第一个困难。 各种配置文件的组织-银行,保险公司,软件开发人员等-为了执行其任务和标准,需要某些类型的网络,这些网络的细节是明确且标准化的。 但是,这不适用于我们。

怎么了

Jet Infosystems是一家大型多学科IT公司。 同时,我们的内部支持部门很小(但是很自豪),它确保了基本服务和系统的可用性。 该公司包含许多执行不同功能的部门:它包括几个强大的外包团队,以及自己的业务系统开发人员,信息安全开发人员和计算机综合体系结构的设计师-总而言之,无论谁都没有。 因此,它们的任务,系统和安全策略也不同。 预期会在需求分析及其标准化过程中造成困难。

例如,开发部门:其员工为大量客户编写和测试代码。 通常,需要快速组织测试环境,而且坦率地说,并非每个项目都总是能够根据所有内部法规形成需求,请求资源并构建单独的测试环境。 这引起了奇怪的情况:一旦您谦虚的仆人进入开发人员房间,并在桌子底下找到了一个运行良好的Hadoop集群,其中包含20个桌面,这莫名其妙地连接到一个公共网络。 我认为没有必要指定公司的IT部门不知道它的存在。 就像许多其他情况一样,这种情况成为了事实的罪魁祸首,即在项目开发过程中诞生了“突变储备”一词,描述了长期遭受苦难的办公基础设施的状态。

或者这是另一个例子。 定期在单元内部设置测试台。 Jira和Confluence就是这种情况,它们在某些项目中仅由软件开发中心使用。 一段时间后,这些有用的资源在其他部门中被发现并进行了评估,并且在2018年底,Jira和Confluence从“本地玩具程序员”的状态转移到“公司资源”的状态。 现在应该为所有者分配这些系统,应该定义SLA,访问/安全策略,备份策略,监视策略,用于对应用程序进行故障排除的路由规则-通常,应该显示完整信息系统的所有属性。
我们的每个部门也是一个培育自己产品的孵化器。 其中一些在开发阶段消亡,其中一些在项目工作期间使用,而另一些则扎根并成为可复制的解决方案,我们开始将自己应用并出售给客户。 对于每个这样的系统,都希望有自己的网络环境,在不干扰其他系统的情况下进行开发,并且在某些时候可以将其集成到公司的基础架构中。

除了开发外,我们还有一个非常庞大的服务中心 ,拥有500多名员工,并为每个客户组成团队。 他们从事网络和其他系统的维护,远程监视,应用程序结算等工作。 也就是说, SC的基础结构实际上就是他们当前与之合作的客户的基础结构。 使用网络的这一部分的特殊之处在于,他们为我们公司提供的工作站部分在外部,部分在内部。 因此,对于SC,我们实施了以下方法-该公司向相应的单位提供网络和其他资源,并将这些单位的工作站视为外部连接(类似于分支机构和远程用户)。

公路设计:我们是运营商(惊喜)


在评估了所有陷阱之后,我们意识到我们正在将电信运营商的网络连接到一个办公室内,并开始采取相应的行动。

我们创建了一个骨干网,借助该骨干网,任何内部(从长远来看)都可以为外部使用者提供所需的服务:L2 VPN,L3 VPN或常规L3路由。 有些部门需要安全的Internet访问,而另一些部门则需要不带防火墙的干净访问,但要保护我们的公司资源和核心网络免受流量的侵害。

对于每个部门,我们非正式地“缔结了SLA”。 根据此规定,应在事先约定的某个时间段内消除所有已发生的事件。 该公司对网络的要求非常严格。 电话和电子邮件故障的最大事件响应时间为5分钟。 典型故障期间网络的恢复时间不超过一分钟。

由于我们拥有电信级网络,因此只能严格按照规则连接。 服务部门制定政策并提供服务。 他们甚至不需要有关特定服务器,虚拟机和工作站的连接信息。 但是同时,由于没有连接会禁用网络,因此需要保护机制。 当意外创建环路时,其他用户不应注意到这一点,也就是说,必须有足够的网络响应。 任何电信运营商都在不断解决其核心网络中看似复杂的任务。 它为具有不同需求和流量的许多客户提供服务。 同时,不同的用户不应受到其他用户流量的不便。
在家里,我们解决了以下问题:我们使用IS-IS协议构建了具有完全冗余的基本L3网络。 使用MP-BGP路由协议 ,在主干之上构建了基于EVPN / VXLAN技术的覆盖网络。 为了加速路由协议的收敛,使用了BFD技术。

图片
网络结构

在测试中,这种方案被证明是极好的-当关闭任何通道或开关时,收敛时间不超过0.1-0.2 s,最少的数据包(通常没有)丢失,TCP会话不会中断,电话对话不会中断。

底衬
参考底线-布线

叠加层
电平叠加-路由

作为分配交换机,使用了具有VXLAN许可证的Huawei CE6870交换机。 该设备具有价格/质量的最佳组合,允许您以10 Gbit / s的速度连接用户,并以40-100 Gbit / s的速度连接到中继,具体取决于所使用的收发器。

图片
华为CE6870交换机

核心交换机使用的是华为CE8850交换机。 从任务-快速可靠地传输流量。 除分配交换机外,没有任何设备与之连接,它们对VXLAN一无所知,因此,选择了具有32个40/100 Gbit / s端口的模型,该模型具有提供L3路由并支持IS-IS和MP-BGP协议的基本许可证。 。

图片
最低的是华为CE8850核心交换机

在设计阶段,团队内部讨论了一些技术,您可以使用这些技术来实现到核心网络节点的故障安全连接。 我们在莫斯科的办公室位于三栋大楼中,我们有7个交叉室,每个交叉室中安装了两个华为CE6870配电交换机(几个交叉室中只安装了几个接入交换机)。 在开发网络概念时,考虑了两个备份选项:

  • 将配电开关组合到每个跨房间的故障安全堆栈中。 优点:简单易用。 缺点:在网络设备的固件中出现错误(“内存泄漏”等)时,整个堆栈出现故障的可能性更高。
  • 应用M-LAG和Anycast网关技术将设备连接到分布交换机。


结果,我们选择了第二个选项。 它的配置有些困难,但是在实践中它已显示出其性能和高可靠性。
考虑首先将终端设备连接到配电开关:
交叉
交叉

两个分发交换机中包括访问交换机,服务器或任何其他需要故障转移连接的设备。 M-LAG技术提供链路冗余。 假设两个配电开关看起来像一台用于连接设备的设备。 冗余和负载平衡是使用LACP协议执行的。

Anycast网关技术可在网络级别提供冗余。 每个分配开关都配置有足够数量的VRF(每个VRF都是为自己的目的而设计的-分别针对“普通”用户,单独-用于电话,单独-用于不同的测试和开发环境等),并且在每个VRF配置了多个VLAN。 在我们的网络中,分配交换机是连接到它们的所有设备的默认网关。 两个分配交换机的VLAN对应的IP地址相同。 流量通过最近的交换机路由。

现在考虑将分布开关连接到内核:
根据IS-IS协议,在网络级别提供了容错功能。 请注意-交换机之间提供一条单独的L3通信线,速度为100G。 从物理上讲,该通信线是直接访问电缆,可以在华为CE6870交换机的照片右侧看到。

另一种选择是组织“诚实”的全连接双星拓扑,但是,如上所述,我们在三座建筑物中有7个交叉房间。 因此,如果我们选择“双星”拓扑,那么我们将需要的确是“远程” 40G收发器的两倍。 这里的节省是非常可观的。

关于VXLAN和Anycast网关技术如何协同工作,我需要说几句话。 如果不做详细介绍,VXLAN是用于在UDP数据包内部传输以太网帧的隧道。 分发交换机的环回接口用作VXLAN隧道的目标IP地址。 每个交换机有两个分别具有相同环回接口地址的交换机,一个数据包可以到达它们中的任何一个,并且可以从中提取以太网帧。

如果交换机知道提取的帧的目标MAC地址,则该帧将正确传递到其目标。 M-LAG机制可在两者上提供MAC地址表(以及ARP表)的同步,它负责确保安装在一个交叉中的两个分发交换机都具有有关来自访问交换机的所有MAC地址的最新信息。 M-LAG对交换机。

由于在底层网络中存在到分发交换机回送接口的多条路由,因此可以实现流量平衡。

而不是结论


如上所述,在测试和运行期间,网络显示出高可靠性(典型故障的恢复时间不超过几百毫秒)和良好的性能-每个网络都通过两个40 Gbit / s的通道与核心交叉连接。 我们网络中的访问交换机堆叠在一起,并通过具有两个10 Gb / s通道的LACP / M-LAG连接到分布交换机。 该堆栈通常具有5个交换机,每个交换机具有48个端口,每个交叉中最多有10个访问堆栈连接到该分布。 因此,即使在最大理论负载下,骨干网也能为每个用户提供约30 Mbit / s的速度,在撰写本文时,这足以满足我们的所有实际应用。

通过网络,您可以轻松地通过L2和L3来组织任意连接的设备的配对,从而完全隔离流量(信息安全服务喜欢)和故障域(操作服务喜欢)。

在下一部分中 ,我们将描述如何迁移到新网络。 敬请期待!

马克西姆·克洛奇科夫(Maxim Klochkov)
网络审计和综合项目高级顾问
网络解决方案中心
喷气信息系统

Source: https://habr.com/ru/post/zh-CN455397/


All Articles