OpenStack应用的数据存储、高可用性及优化策略

### OpenStack应用的数据存储、高可用性及优化策略 #### 1. 数据存储 在OpenStack中，数据存储有多种方式，每种方式都有其特点和适用场景。 - **临时存储（Ephemeral Storage）**：实例启动时默认使用临时存储，它通常与实例运行的计算节点相关联。如果实例终止，与之关联的所有临时存储也会被删除。临时存储是OpenStack中保护程度最低的数据存储方式，可能没有备份或复制，磁盘丢失或计算节点故障都可能导致数据丢失。 - **块存储（Block Storage）**：由Cinder提供，以卷的形式呈现，可以附加到实例上。卷在实例内部显示为块设备，可以作为磁盘或文件系统挂载。卷可以附加、分离并移动到不同的实例。当实例终止时，卷会从实例中分离，但不会被删除，必要时可以附加到新实例。块存储通过驱动程序实现，很多驱动程序是特定于供应商的。通常，块存储会设置为高性能，并复制数据以防止数据丢失。 - **对象存储（Object Storage）**：通过Swift API提供，数据存储方式与块存储完全不同。应用程序创建容器，然后将文件上传到这些容器中。访问文件需要将其从容器下载到实例中。容器及其关联的文件与实例无关，如果使用某个容器的实例终止，容器或其文件不受影响，仍可被云中的其他实例访问。Swift相对于Cinder的一个优势是，多个实例可以访问同一个容器，而块存储卷一次只能被一个实例附加和访问。对象存储也通常设置为高性能，并复制数据以防止数据丢失。 在构建需要永久存储数据的应用程序时，选择合适的数据存储后端非常重要。需要考虑以下问题： 1. 数据的重要性如何？ 2. 如果实例死亡，数据丢失是否可以接受？ 3. 如果创建新实例，数据是否可以替换或重建？ 4. 数据需要保存多长时间？ 5. 数据是否需要始终立即可用？ 6. 需要存储多少数据？ 建议与存储管理员沟通，了解可用选项，特别是数据复制设置、可用存储量以及应用程序的长期需求，以便进行相应的规划。如果数据存储在具有数据复制功能的环境中，应用程序应避免自行进行数据复制，以免造成不必要的性能影响和磁盘空间浪费。应用程序可以同时利用多种存储选项，例如将常用数据存储在临时存储中，不常用的数据存储在块存储中，极少使用的数据存储在对象存储中进行长期存储。 #### 2. 高可用性 构建高可用性的应用程序意味着应用程序要尽可能保持可用，并且在任何时候都能正常运行并保持高性能。高可用性应用程序通常可以在多个地方运行，并能适应运行环境的变化。 实现高可用性应用程序的一些技术包括： - **多实例运行**：确保应用程序及其所有组件可以在多个实例中运行，并且这些实例可以在多个环境中运行。应用程序运行的地方越多，对硬件甚至数据中心故障的恢复能力就越强。多个实例还允许应用程序根据需要进行适当扩展。 - **使用负载均衡器**：将服务置于负载均衡器之后，以便适当分配流量。如果某个实例不可用，负载均衡器会自动将该服务从池中移除，并将流量重新分配到其余服务。使用全局服务器负载均衡（GLSB）可以根据连接来源将流量重定向到不同的数据中心，进一步提高高可用性。如果某个数据中心离线，GLSB可以自动将所有流量重定向到另一个数据中心，直到问题解决。 - **了解应用程序使用情况**：外部事件可能导致流量使用量显著增加，如节假日购物、体育赛事、学校开学等。在构建高可用性应用程序时，需要考虑这些因素。理想情况下，如果可以提前预测事件，应用程序可以在事件发生前相应地进行扩展，以应对预期需求，事件过去后再进行缩减。 应用程序可以通过以下方式进行扩展以满足需求： - **手动扩展**：有人主动监控服务，并根据需要手动添加实例，直到应用程序能够处理需求。这种方法成本较高，并且引入了人为因素和风险。 - **自动扩展**：监控应用程序的问题和性能，并以务实的方式自动扩展应用程序。OpenStack提供了许多用于管理云中实例和服务的API，应用程序可以检测何时需要扩展特定服务，并使用API进行操作。当需求减少时，应用程序可以自动减少运行的实例数量。 此外，提前在应用程序中构建额外的容量也是一个重要策略。不要期望每个实例都100%忙碌，只部署处理所有负载所需的实例数量，而是将每个实例设置为60%忙碌，并运行更多实例。这样可以处理短暂的容量高峰，而不会触发自动扩展，避免影响应用程序的性能。 然而，高可用性也带来了其他挑战，例如“裂脑综合征（split - brain syndrome）”。当某个服务在多个实例中运行，其中一个实例作为主实例，其他实例作为被动实例时，如果主实例和被动实例之间的通信中断，可能会导致多个被动实例同时进入主模式，出现多个主服务器同时运行的情况。这种问题在网络通信中断的区域之间可能更加明显。 #### 3. 应用程序优化 下面以一个简单应用程序为例，介绍如何对其进行优化。该应用程序有三个组件：用户访问的基于Web的前端、前端与之通信的API层以及数据库后端。 ##### 3.1 简单应用程序 最初，为了提供概念验证，确保应用程序在云中可行并获得继续开发的批准，应用程序可能保持简单，每个组件可能只有一个实例。 #####