任何技术设备的寿命都是有限的，到了一定时候，设备就必须得更换。最近，Westminster大学的需要更换存储设备 – 一套基于iSCSI的SAN，这套用于生产环境的SAN使用寿命即将结束。就个人而言，我觉得现实世界中的故事更具说服力，更有参考价值，因此我决定和大家分享一下我们从老的iSCSI SAN过渡到新的光纤通道SAN所经历的一些事情。
负荷超重的iSCSI SAN
首先，我介绍一下背景，我们的iSCSI SAN支持大量的工作负载，包括：
1、在4台vSphere 4.0/4.1主机上运行着由50个虚拟服务器组成的VMware集群;
2、我们的Exchange 2007邮箱存储：我们的Exchange 2007系统完全是物理的，它运行在iSCSI SAN上;
3、我们的主数据库服务器数据库：我们的主SQL Server是一台物理服务器，所有数据库都存储在iSCSI SAN上。
虽然我们事先并没有规定一定要选择光纤通道解决方案，但最终我们还是选择了它。虽然我对光纤通道了解得不多，但我知道它的性能更好，坦率地说，我最初的想法是继续使用iSCSI，不想考虑非iSCSI解决方案，但我们的决策并没有受这个想法限制。
下面是2011年3月之前我们看到的基础设施：
iSCSI SAN：两个具有冗余路径的可管理模块，存储系统是完全冗余的。
一个戴尔M1000e刀片机箱：背面安装了6块M3220以太网刀片，每块以太网刀片连接到每台服务器中的一个网卡端口。
4台VMware ESX主机：每台配有6个以太网端口(3块网卡，2块板载网卡和2块双端口独立网卡)，每个端口映射到机箱背面得一个以太网交换模块，开始时，有3台ESX主机配有32GB内存，1台配有48GB内存。
我们面临一些挑战，首先，为了转移到光纤通道，我们需要使用光纤通道卡更换每台服务器中的以太网卡，因此也要更换刀片机箱中的2个以太网交换模块，以便和服务器中新安装的光纤通道卡匹配。
虽然M1000e机箱允许热插拔刀片，但当一或多台服务器有另一种类型的网卡时，你就不能更换别的类型的刀片，因此，只要槽中有任何配有以太网卡的刀片服务器，我们就不能在机箱中安装光纤通道模块，经过我们尝试，机箱有一个机制停用通信槽，以防止损坏系统。因此，我们首先要做的事情是检查所有服务器，将所有独立以太网卡全部移除，之后我们还增加了一台新的ESX主机。
新增设备
作为这个迁移过程的一部分，我们还决定将其中一台32GB内存的ESX服务器撤下，使用一台96GB内存的服务器顶替，因为我们的集群越来越受到内存的约束，信不信由你，给服务器增加内存和延长保修期比购买一台新服务器还贵，新服务器配有两颗6核心处理器，而旧服务器只有两颗4核心处理器，因此，我们不但节省了成本，还拥有更多的内存和处理核心。
我们从在新服务器上安装vSphere 4.1u1拉开这次迁移工程的序幕，应用一个主机配置文件，再将新服务器添加到我们的vSphere集群中。
非暴力迁移
显然，我们在完成迁移目标时需要尽可能少停机，因此我们没有使用暴力，从第一台vSphere服务器开始，我们将主机切换到维护模式，通过vCenter和vMotion将资源和工作负载自动转移到集群中的其它主机，包括我们新增加的96GB内存，12处理核心的服务器，当所有工作负载全部“撤离”后，我们把服务器从机箱中抽出来，移除独立以太网适配器，并安装上光纤通道适配器。
但在处理第一台服务器时，我们就遇到了问题，我们原本想的是将以太网卡拔出，插入新的光纤通道适配器，将其放回机箱，重新加电即可。前面几步进行得都还顺利，但系统启动时出问题了，经进一步研究，我们确定了问题的根本原因，如果刀片机箱中任何服务器还插有需要更换成光纤通道适配器的以太网卡，服务器就不能启动，根据戴尔官方的说法，这样设计是为了预防对整个系统产生破坏，于是我们对计划做出了修改，我们将刚刚安装上去的光纤通道卡拆下来，重新将服务器放回机箱，并退出维护模式，系统启动正常了，也能托管工作负载了。于是，我们逐个检查vSphere主机，将它们的独立以太网适配器移除，再将它们放回机箱，恢复到正常工作模式。
当所有以太网适配器全部移除后，我们在服务器机箱背面安装了光纤通道交换模块，我们成功了，模块加电后一切正常。
接下来，我们对所有vSphere服务器都成功安装了光纤通道适配器，我们从服务器机箱移除刀片，再安装光纤通道适配器，安装好后，我们重启系统，使其重新进入生产状态，但有一个例外，我们将1台32GB内存，8处理核心的vSphere主机做了退役处理，将它的许可转移给了新增加的96GB内存，12处理核心的主机，这也是我们更换策略的一部分。
第一个光纤通道改造项目
当所有服务器都装上光纤通道适配器后，我要确定服务器机箱背面的光纤通道交换模块可以看到所有光纤通道端口，我将新SAN连接到新光纤通道交换模块上的扩展端口，并从每个光纤通道交换模块到存储阵列每个管理模块上各个光纤通道端口创建了一个连接。
我承认，这是我第一个光纤通道改造项目，幸运的是，它是小菜一碟，我在每个光纤通道交换模块上创建一个区，给每个新区添加相应的交换机端口，最后，我配置了vSphere主机，确保它们能看到新SAN上的卷，为此，我还创建了一个很小的测试卷。
虚拟机集群迁移
至此，舞台已经搭好，所有vSphere服务器都可以同时看见旧的和新的存储设备，我在新存储阵列上创建了新的LUN，新的VMFS卷，接着，我对50个虚拟服务器启动了Storage vMotion操作，让所有虚拟机从iSCSI SAN迁移到光纤通道SAN，同样，这个过程也做到了(几乎)无停机，和前面的硬件更换过程一样。
Storage vMotion过程大概花了两天时间完成，在迁移其中一个虚拟机时，我遇到了一个小小的问题，我果断将其关闭，很快结束了迁移，但还是延长了维护窗口，这算是一点遗憾。
结果
最终结果是：所有运行在基于VMware的工作负载全部转移到了新的存储阵列，只有一个非关键的工作负载停机了一会儿，上面描述的所有工作都是在不停机的情况下完成的，经历了工作时段和非工作时段，所有硬件更换工作都是在工作时间完成的，vMotion工作更是经历了白天和夜晚。
放在几年前，这种项目如果在工作时段执行将会是一件疯狂的事情，因为以那时的技术，这种迁移工作需要较长的停机时间，迁移期间业务将受到重大影响，但是，在150多个vMotion操作的帮助下，我们可以非常快速地完成迁移任务，对企业业务也不会产生多少负面影响，这正是虚拟环境带来的好处，这种快速迁移能力也是虚拟化基础设施日益得到重视的驱动力。
还有更多
在文章前面部分，我提到了部分运行SQL和Exchange工作负载的物理服务器也使用了iSCSI SAN，另外，有一部分工作负载因租约到期，也需要转移到新硬件，特别是还有两台物理服务器支持我们的SharePoint 2007环境 – 一台MOSS 2007服务器和一台专用SQL 2005服务器，所有SharePoint和SQL环境中的数据都保存在本地，没有驻留在旧的SAN上。
我们做了什么?
我们的Exchange 2007系统托管了1300名学生和教职员工的邮箱，所有邮件都存储在iSCSI SAN上，Exchange Server本身是一台物理服务器，我们使用PlateSpinPowerConvert执行P2V操作，将这台物理服务器迁移到新的可扩展的vSphere集群，我们将这个操作放在了周六夜间执行，现在已经完成了工作负载的虚拟化，也就将Exchange 2007数据库从iSCSI SAN移除了，它们现在和虚拟机一道存储在新的光纤通道SAN中。
我们的机构网站是使用SharePoint 2007系统搭建的，运行至今大约有3年历史了，物理服务器使用了直接附加存储(NAS)，同样，我们使用P2V操作虚拟化了所有SharePoint工作负载。
SQL 2005是SharePoint 2007专用数据库，也使用了直接附加存储，同样，我们也使用P2V操作虚拟化了这个关键工作负载。
留下了什么?
至此，我们已经将多台物理服务器虚拟化，我的主数据库服务器是一个刀片服务器，运行着SQL Server 2008 R2，这台服务器上的所有数据都存储在iSCSI SAN上，不幸的是，现在仍然如此，虽然我已经可以熟练执行P2V操作，但对数据库来说，这个过程仍然很漫长，我只有等到下一个周末看是否能抓住机会完成这个操作。
小结
总的来说，我对最终结果感到非常满意，虽然中间出了一点状况，但我们还是没有遇到特别大的困难，我们可以非常快速地将整个VMware资源转移到新存储，并通过使用P2V软件进一步整合/虚拟化物理资源。到目前为止，我们环境中大约90%的资源都实现了虚拟化，在接下来的维护期中，我们的工作将变得更轻松，新的SAN给我们提供更好的性能和更大的容量，它将帮助我们成长。
