系统迁移注意事项_云迁移和转换网络注意事项

系统迁移注意事项

Clea Zolotow, FBCS, Distinguished Engineer and Master Inventor, Worldwide Client Technology Engagement, GTS Infrastructure Services, IBM

Clea Zolotow ，FBCS，杰出的工程师和发明家，全球客户技术合作，GTS基础架构服务，IBM

Rebecca Huber, Executive Cloud IT Architect, Cloud Application Innovation, GBS, IBM

Rebecca Huber ，IBM，GBS，云应用创新，执行云IT架构师

Hasibe Göçülü, IBM Senior Certified Architect, Cloud Migration and Modernization, GTS, IBM

HasibeGöçülü ，IBM GTS，云迁移和现代化，IBM高级认证架构师

介绍 (Introduction)

In migration programs, networking is generally underestimated. The dependencies on network are not considered from a cost savings, optimization, and migration aspect. The role of networking in migration needs a thorough planning and a planned execution with a proper understanding of the network design and the inputs from discovery phase including application dependencies, subnets, VLANs, and especially security and firewall planning.

在迁移程序中，网络通常被低估。 从节省成本，优化和迁移方面考虑，不考虑对网络的依赖性。 网络在迁移中的作用需要进行透彻的计划和有计划的执行，并且要对网络设计以及发现阶段的输入有适当的了解，包括应用程序依赖性，子网，VLAN，尤其是安全性和防火墙计划。

波浪规划 (Wave Planning)

As we have talked about in our 2nd blog: Wave Planning a successful migration strategy is planned around grouping of tightly coupled servers. Utilizing the same migration event, these servers will be migrated together in a single maintenance window. The grouping of the servers will be based on their “application affinity.” From a networking perspective, it means the servers that create one more application dependent on each other can reside in one or several VLANs which need to be migrated together. Otherwise, a stretched application may experience elongated transaction response times and database timeouts. This could lead to a situation with no resolution except rolling back the migrated application.

正如我们在第二篇博客：Wave Planning中讨论的那样，围绕紧密耦合的服务器的分组计划了成功的迁移策略。 利用同一迁移事件，这些服务器将在单个维护窗口中一起迁移。 服务器的分组将基于它们的“应用程序相似性”。 从网络角度来看，这意味着创建彼此依赖的另一个应用程序的服务器可以驻留在一个或多个需要一起迁移的VLAN中。 否则，拉伸的应用程序可能会经历延长的事务响应时间和数据库超时。 除了回滚已迁移的应用程序之外，这可能导致无法解决的情况。

In a successful and optimal migration, planning needs to be created with an in-depth understanding of the application affinity, including tightly coupled and loosely coupled applications. For example, a tightly coupled application has to move together to avoid high response times. A loosely coupled application, such as a mainframe offload to an AIX database, doesn’t have to move together as the application can tolerate longer latency.

在成功且最佳的迁移中，需要在深入了解应用程序亲和力(包括紧密耦合和松散耦合的应用程序)的基础上创建计划。 例如，紧密耦合的应用程序必须一起移动以避免高响应时间。 松散耦合的应用程序(例如大型机卸载到AIX数据库)不必一起移动，因为该应用程序可以忍受更长的延迟。

重新IP和网络设置 (Re-IP and Networking Settings)

It is usually considered a value add to the data center migration to receive a new IP address in the target security zone in the cloud data center, in order to avoid conflicts and collisions on the network. This activity as cleans up the existing networking IP in the current datacenter as well. Many times, the data center network has been around for so long that it is undocumented and doesn’t have the resiliency at network layer, with separate VLANS for administration, production, and backup. (IP Addressing and Subnetting for New Users — Cisco, n.d.)

通常将其视为增加数据中心迁移的附加值，以便在云数据中心的目标安全区域中接收新的IP地址，以避免网络上的冲突和冲突。 此活动还可以清除当前数据中心中的现有网络IP。 很多时候，数据中心网络已经存在了很长时间，以至于它没有文档记录，并且在网络层上没有弹性，并带有用于管理，生产和备份的单独VLAN。 ( 新用户的IP寻址和子网划分-Cisco ，第二版)

Figure 1: Gain vs. Pain of Transformation(Ramasamy et al., n.d.)

图1：转换的收益与痛苦(Ramasamy等，nd)

For image migrations that are congruent with the target cloud environment, IP addresses and related network settings are automatically adjusted on the OS instances during normal washing (or blue wash for IBMers), utilizing the migration tools or automation scripts executed after migration. For re-installation and re-platforming scenarios, the servers get new IP addresses as part of the normal provisioning with the orchestration layer in the cloud (IBM Cloud VPC — Networking | IBM, n.d.).

对于与目标云环境一致的映像迁移，将在迁移后执行的迁移工具或自动化脚本中，在常规清洗(对于IBM用户为蓝色清洗)期间，在OS实例上自动调整IP地址和相关的网络设置。 对于重新安装和重新平台化的情况，服务器将新的IP地址作为具有云中业务流程层的常规配置的一部分( IBM Cloud VPC-Networking | IBM ，nd)。

Applications using IP addresses directly rather than DNS names (hard coded IP addresses) need to be reconfigured by their owners to use the corresponding DNS name during the application remediation phase as a migration readiness step. As direct IP addressability is not usually allowed into the cloud due to inflexibility. This direct IP to DNS conversion should be performed before the actual migration. Although it is highly recommended to reduce the changes during migration and leave those changes to before or after the migration, sometimes it may not be possible: in certain clusters or mainframe communication. In these cases, the runbook that is created for the migration event has to contain the necessary steps for the application owners to make the necessary changes for the affected components make the IP address changes.

直接使用IP地址而不是DNS名称(硬编码IP地址)的应用程序需要由其所有者重新配置，以在应用程序补救阶段作为迁移准备步骤使用相应的DNS名称。 由于缺乏灵活性，通常不允许直接IP寻址到云中。 从IP到DNS的直接转换应在实际迁移之前执行。 尽管强烈建议减少迁移期间的更改并将这些更改留在迁移之前或之后，但有时可能无法实现：在某些集群或大型机通信中。 在这些情况下，为迁移事件创建的运行手册必须包含必要的步骤，以便应用程序所有者对受影响的组件进行必要的更改，以进行IP地址更改。

It is important to note that many application owners will not know if they have hardcoded IP addresses. For example, to detect whether an application uses a particular IP address to communicate to other systems would require a custom way to read the specific configurations and read the addresses (US20170033994A1 — Identifying Hardcoded Ip Addresses — Google Patents, n.d.). This is not a trivial task as it is variable for custom applications and is typically dealt with as risk during a migration event. Testing can be performed prior to a migrated system being turned on into production. However, that can be costly upfront, to mitigate at the time of migration or missed completely due to missing test cases and can cause major issues in the future.

重要的是要注意，许多应用程序所有者不知道他们是否具有硬编码的IP地址。 例如，要检测应用程序是否使用特定IP地址与其他系统进行通信，将需要一种自定义方式来读取特定配置并读取地址( US20170033994A1-识别硬编码的IP地址-Google Patents ，nd)。 这不是一项琐碎的任务，因为它对于定制应用程序是可变的，并且通常在迁移事件期间作为风险处理。 可以在将迁移的系统投入生产之前执行测试。 但是，这可能是昂贵的前期准备，以减轻迁移时的损失或由于缺少测试用例而导致的全部遗漏，并且将来可能会引起重大问题。

The approach to gather this information, without having to perform system scans, is to compare name resolution caches to server communication attempts. This can be done using a layer 2 to layer 3 mapping (MAC address to IP address mapping) or it can be done directly using layer 3 operating system commands (see the patent above).

无需执行系统扫描即可收集此信息的方法是将名称解析缓存与服务器通信尝试进行比较。 这可以使用第2层到第3层映射(MAC地址到IP地址的映射)来完成，也可以直接使用第3层操作系统命令来完成(请参见上面的专利)。

Software licenses may also be affected with the change in IP addresses; if this requires procurement or other interaction with the software vendor, this has to be planned for the application remediation phase.

如果需要采购或与软件供应商进行其他交互，则IP地址更改也可能会影响软件许可证。这必须在应用程序补救阶段进行计划。

In some migration programs the hosts will also get new hostnames. The migration team, platform SMEs and the application owner should work together to do the necessary changes at every component to alter all addressing to the new DNS names. Such migrations require extended testing.

在某些迁移程序中，主机还将获得新的主机名。 迁移团队，平台中小型企业和应用程序所有者应共同努力，对每个组件进行必要的更改，以将所有地址更改为新的DNS名称。 这种迁移需要扩展测试。

网络带宽和延迟注意事项 (Network Bandwidth and Latency Considerations)

This section describes strategy aspects related to the DC LAN and WAN during the migration to the cloud or other new data centers. A precondition for migration is that the network is capable of handling the productive network traffic load. Note that bypassing the LAN and utilizing WAN only transfer methods is highly recommended with large migration loads due to overweighing the LAN as well as uplink problems on the production network core.

本节介绍了在迁移到云或其他新数据中心期间与DC LAN和WAN相关的策略方面。 迁移的前提条件是网络能够处理生产性网络流量负载。 请注意，强烈建议使用绕过LAN且仅使用WAN的传输方法，以应对较大的迁移负载，这是因为LAN的负担以及生产网络核心上的上行链路问题。

Figure 2: Migrations Utilizing LAN with DoubleTake Example

图2：使用LAN和DoubleTake示例进行迁移

During the migration, additional network bandwidth is needed between the source and target environment. The exact capacity amount needed depends on the planned move groups, schedule, amount of the data to be moved and the migration strategy: one time data copy or continuous replication. If all data is transferred while the applications are down, the bandwidth can be computed using the storage size of move group, divided by the length of the change window, plus the typical network overhead. If data is transferred while the applications are running and few hours or days before the migration event, a more complex computation based on the change rate is needed. If the bandwidth has to be ordered earlier than the move groups are available, an estimate has to be made based on the overall storage and the expected available time for change windows.

在迁移期间，源环境和目标环境之间需要额外的网络带宽。 所需的确切容量取决于计划的移动组，计划，要移动的数据量和迁移策略：一次数据复制或连续复制。 如果在应用程序关闭时传输了所有数据，则可以使用移动组的存储大小除以更改窗口的长度再加上典型的网络开销来计算带宽。 如果在应用程序运行时以及迁移事件发生前几小时或几天传输数据，则需要基于更改率的更复杂的计算。 如果必须在移动组可用之前订购带宽，则必须根据总体存储和更改窗口的预期可用时间进行估算。

Note that latency is generally accepted to be 10 ms per 1000 miles. In some cases, WAN accelerators may be utilized to decrease latency. WAN Accelerators (WANX) encapsulate the TCP/IP packet to ensure that the short acknowledgement required by native TCP/IP is overridden. Some examples of WAN accelerators are Riverbed devices such as Steelhead and Cisco’s Wide Area Application Services (WAAS). The latency needs to be taken into account when doing the wave planning as mentioned earlier in the article.

请注意，通常认为延迟是每1000英里10毫秒。 在某些情况下，可以使用WAN加速器来减少延迟。 WAN加速器(WANX)封装TCP / IP数据包，以确保本机TCP / IP所需的简短确认被覆盖。 WAN加速器的一些示例是Riverbed设备，例如Steelhead和思科的广域应用服务(WAAS)。 如本文前面所述，在进行波浪规划时需要考虑延迟。

Networking lines such as OC3 and 10 GB/E have a stated payload (maximum of the line) as well as an assumed effective rate which is considered to be anywhere from 60 to 80% of line capacity depending on the overhead of the line. Therefore, a 10 GB/E would have an effective capacity of between 6 and 8 GB/E.

诸如OC3和10 GB / E之类的网络线路具有规定的有效负载(线路的最大值)以及假定的有效率，根据线路的开销，该有效率被认为是线路容量的60％至80％。 因此，10 GB / E的有效容量将介于6和8 GB / E之间。

When calculating datacenter migration line speeds it is also important to note that lines do not run at capacity for a 24 hour period. There are starts and stops inherent in the wave planning, therefore effective daily throughput is estimated based on a 15 hour day. Firewall settings for the migrated applications have to be planned beforehand, based on dependency discovery and application questionnaires or on existing firewall rules (Hunt et al., 2012)(Zolotow et al., n.d.).

在计算数据中心迁移线速度时，还必须注意，线在24小时内不会满负荷运转。 波浪规划中固有的起止点，因此，基于15小时的工作日估算有效的每日吞吐量。 必须根据依赖关系发现和应用程序调查表或现有的防火墙规则(Hunt等人，2012)(Zolotow等人，nd)预先计划迁移后的应用程序的防火墙设置。

As a general rule, all external network connections (inbound and outbound) will be blocked during tests, except the protocols required for the actual migration and, in a later stage, for the UAT. One key mechanism for this blocking is firewall rules. The firewall rules for both the ring fencing period and the final state have to be planned in advance during the planning phase for each business application. If firewall protection is not feasible for the ring fencing because of specific communication patterns, careful detailed design of another approach is needed. Similarly, load balancer configurations have to be performed before or in migrations.

通常，在测试过程中，所有外部网络连接(入站和出站)都将被阻止，但实际迁移所必需的协议以及在以后的UAT中所需要的协议除外。 这种阻止的一种关键机制是防火墙规则。 必须在计划阶段为每个业务应用程序预先计划环形防护期和最终状态的防火墙规则。 如果由于特定的通信模式而无法对环网进行防火墙保护，则需要仔细设计另一种方法。 同样，必须在迁移之前或迁移期间执行负载均衡器配置。

摘要 (Summary)

As we have seen, a proper understanding and planning of network is essential in Cloud Migration and modernization. The ability to re-IP is a considered to be a bonus as it cleans up the network addressing scheme. It’s also important to size the lines correctly, knowing that 100% of the line capacity is not used and the workday usually isn’t 24 hours.

正如我们所看到的，对网络的正确理解和计划对于云迁移和现代化至关重要。 重新IP的能力被认为是一项奖励，因为它可以清理网络寻址方案。 正确确定生产线的尺寸也很重要，要知道没有使用生产能力的100％，而且工作日通常不是24小时。

In our next blog post in the series on Cloud Migration and Transformation, we will talk about testing.

在有关云迁移和转型系列的下一篇博客文章中，我们将讨论测试。

翻译自: https://medium.com/swlh/cloud-migration-and-transformation-network-considerations-2c61c414fbab

系统迁移注意事项