传统数据迁移
传统文件迁移通常采用以下两种方式之一进行:反复同步或外部插入。
通过同步进行迁移
这种方法使用活动的主机 X 向新主机 Y 迁移数据,同时主机 X 仍然保持活动状态。在迁移过程中,客户机仍然对原始主机进行读写操作。在进行初次迁移后,将反复地发送增量更改数据,一直到增量数据少到足以在一个停机时段内发送完毕为止。此时,原始共享资源将变为只读状态,最后一部分增量数据将发送到新主机,而所有客户机将更新为指向该新位置。实现这种迁移的最常用方法是通过 rsync 工具,但是还有其他集成的工具可用。这种方法有几个缺点:
尽管预期的停机时间较短,但不易量化。如果用户在计划的停机时间即将到来之前提交了大量更改数据,将会延长停机时段。
在迁移期间,新服务器处于空闲状态。因为新服务器往往具备新的功能或性能上的改进,所以,这会在可能很长的迁移期间内造成资源浪费。
在多个文件系统之间协调的任务很繁重。在迁移数十个或数百个文件系统时,每次迁移都需要不同长短的时间,因此,必须在所有文件系统构成的联合体内计划好各自的停机时间。
通过外部插入进行迁移
这种方法使用活动的主机 X,并另外加入一个新 ZFSSA M,由后者将数据迁移到新主机 Y。所有客户机会立即更新为指向 M,而数据自动在后台进行迁移。这可以为迁移选项带来更多灵活性(例如,能够将来在不停机情况下向新服务器进行迁移),并可以利用新服务器来处理已迁移的数据,但也有一些显著的缺点:
迁移 ZFSSA 作为新的物理机,产生相关成本(初始投资、支持成本、供电和冷却等)及其他管理开销。
迁移 ZFSSA 成为系统中新的故障点。
迁移 ZFSSA 插入已迁移的数据,这样会产生额外的延迟,通常是永久性的。这些迁移 ZFSSA 通常需要持续运行,当然也可以为其另外计划停机时段并将其停用。