Latest News

数据中心迁移检查清单 六个关键的迁移考虑因素 从一个数据中心迁移到另一个数据中心，或者从一个数据中心迁移到云端。这个过程很困难，但有时很必要。迁移你的应用软件、基础设施软件（有时是迁移硬件）非常复杂。 除了将软件迁移到新的基础设施，以及有时迁移基础设施本身的业务之外，还有一些关键的数据中心迁移最佳实践，它们可确保数据不会丢失，而且不允许出现计划外的停机。对于更加重要的应用程序来说，计划外的停机必须安排在正常工作时间之外，这就使得这一过程更加困难。 作为初步的高级指南，我们编制了一份简便的数据中心迁移检查清单。在执行如此复杂的项目时，IT 经理必须始终协商财务限制条件、法律义务以及后勤方面的挫折，等等。也就是说，有了正确的数据中心迁移计划，值得付出努力。从传统的基础设施进行迁移的公司可以改进性能，使迁移后的系统实现更加高效的管理和运维，并从中受益。 此迁移过程涉及到通过复杂的互联服务网络进行工作　──　很少像“升降和转移”那么简单，并且经常会出现关于当前 IT 资产（服务器、网络、数据库等）的不完整信息。这意味着，很难弄清任何系统的完整部件清单，以及关闭某些部件后将停止工作的部件。 那么，在进行数据中心迁移时需要注意哪些关键的迁移考虑因素？我们整理了六点，你应将它们添加至你的数据中心迁移检查清单中。 1.　了解在你的数据中心发生了什么 数据中心迁移检查清单的第一项，是了解在你当前的数据中心发生了什么。每个计算环境都是由关系组成的：影响其他应用程序和系统的功能和行为的应用程序和系统。 但是，如果你不了解这些应用程序和系统之间的关系，这可能会扰乱你的数据中心迁移。事先很少能完全了解数据中心中所有的部件和交互，因为随着设置旧版系统结构关系的员工的离职，通常会随之带走重要的知识。 使用网络跟踪工具可以帮助你建立部件之间的确切关系，以及相互关联的方式。如果你在进行迁移前的几个月内使用，就有可能最全面地了解你的数据中心的工作情况。你的系统中有一些部件可能每几个星期、几个月，甚至到年底才会彼此进行通信，因此建议你在尽可能长的时间内进行观察。 2.　为每种应用程序选择合适的迁移方式 数据中心迁移检查清单的第二项是决定迁移方法。对于每种应用程序来说，通常存在几种不同的迁移方法，具体包括“升降和转移”　──　物理移动硬件；重新安装应用程序并迁移数据；恢复计算机图像；以及将虚拟机复制到新的数据中心。至于何种方法最佳，取决于应用程序目前使用的技术。 确定了迁移方法之后，有必要决定是否执行试迁移、要做多少测试，以及审批流程应有多严格。应用程序越重要，值得进行试迁移的可能性就越大。适合进行的测试越多，审批流程就应越严格。例如，如果该应用程序用于预订会议室，流程就比该应用程序执行空中交通管制更简单。 如果有很多应用程序都在迁移的范围内，可以根据任务的关键程度（即重要性）和应用程序所使用的技术，制定一个矩阵，以快速确定迁移方法。使用旧技术的应用程序（例如旧式微型机）是“升降和转移”的候选对象。最新应用程序有可能在虚拟机上运行，而且可以将虚拟机复制到目标环境。 3.　熟能生巧 对于更重要的应用程序，一般需要进行试迁移。迁移重要的应用程序常常还涉及到传输敏感信息。该信息应进行安全备份，在迁移的每个阶段，应制定全面的重新运行计划。换句话说，应始终制定能恢复到尝试迁移之前的状态的计划，以防在应用程序迁移过程中出现任何错误。 对于大多数应用程序来说，数据中心迁移检查清单的一个关键项是在实际实施之前，在目标环境中运行试迁移。在进行试迁移时，实时应用程序将继续在现有环境中运行。执行试迁移并不一定能保证所有潜在问题都得到解决，但可以帮助你提前预测和纠正许多问题。 想要加快你的迁移？请查看我们的　OpsWave 手册。 4.　为传统系统做好准备 处理传统的应用程序是检查清单中的下一项。很多机构都依赖于 IT 系统，因为 IT 系统经受住了时间的考验，在首次安装几十年后仍然可以提供良好的服务。将它们过渡到新的数据中心　──　甚至更多地迁移到云端　──　可能远非如此简单。 如果将运行在比如说 VAX（20 世纪 90 年代受欢迎的微型机）上的应用程序迁移到另一个常规数据中心，则可以通过升降和转移来进行迁移。如果不是这样（迁移到云端的情况属于此类），则必须先将该应用程序移植到 VAX 仿真器，然后才能进行迁移。 即使这样，网络或其他约束条件也可能使仿真器无法运行，唯一可用的选项可能是重写某些应用程序或完全替换/放弃该应用程序。 5.　为新网络中的应用程序认真计划预定的空间 就你的数据中心迁移策略而言，每种应用程序都必须在你的新网络中占有一席之地。这在你的数据中心迁移检查清单中至关重要，需要进行大量的工作。你必须考虑域、防火墙设置等，同时还要考虑哪些旧版应用程序与你的新数据中心的安全性兼容，哪些不兼容。 在有些情况下，可能需要重写应用程序的各个方面，以便与你的新安全措施相一致。这可能非常耗时，而且成本高昂，但是替代方案会因具体情况而让你的网络安全措施变得松弛　──　可能更不可取。...

经常有人问我们应该何时从 Jira 云端版迁移到服务器版。这是一个常见的问题；小型开发团队或大型机构中的单个开发人员会设置一个 Jira 云端版实例来支持其开发工作。随着时间的推移，该实例会成为开发团队不可或缺的一部分，并开始得到更广泛的使用。此时，问题开始浮现，例如为附件分配的空间量、总体用户数，甚至需要与公司的 Active Directory 相集成。 此时客户必须考虑是否从 Jira 云端版迁移到服务器版，但何时是迁移的最佳时机呢？ Jira 云端版到 Jira 服务器版：了解关键区别 为了更清楚地了解你为什么需要从 Jira 云端版迁移到服务器版，或从 Jira 服务器版迁移到云端版，并帮助确定何时是迁移的良好时机，让我们看看这两种产品之间的区别。 想要在较大范围内更好地运行敏捷项目？ 请立即观看我们的 JIRA PORTFOLIO 展示 如果你使用的是网络应用程序，那么你会始终使用最新版本的 Jira，并且网站的设置需要花费几分钟时间。此外，由于实例本身由 Atlassian 进行维护，因此服务器端的管理会被完全移除，从而减少实例维护所需的时间。 当客户倾向于不使用 Jira 云端版时，通常是由于以下其中一项原因所致： 　 用户数量存在硬性限制（最多 2000 位） 　 附件的数据存储空间大小存在硬性限制（用户基数大于 500 时为...