运维 - D2iQ Docs

DC/OS Apache Cassandra 服务提供强大的 API（HTTP 或 DC/OS CLI 可访问），用于管理、维修和监控服务。此处，为简洁起见，仅谈及 CLI 版本，但请参阅 API 参考了解 HTTP 说明。

计划操作

DC/OS Apache Cassandra 服务实例根本上是一套计划（如何运行服务）和一组 Pod（运行什么）。服务主要由两个计划驱动，deploy 和 recovery。

deploy 计划在初始安装以及配置和服务更新期间使用。recovery 计划是一项始终运行的计划，可确保应该运行的 Pod 和任务保持运行。其他计划（“sidecars”）用于二次操作。

每个计划由一组阶段组成，每个阶段由一个或多个步骤组成。

列表计划

可使用 CLI 命令检索计划列表：

$ dcos cassandra --name=cassandra plan list

检查计划

使用 CLI 命令查看计划的当前状态：

$ dcos cassandra --name=cassandra plan status <plan-name>

例如，服务计划已部署完成的状态为：

dcos cassandra --name=cassandra plan status deploy
deploy (serial strategy) (COMPLETE)
└─ node-deploy (serial strategy) (COMPLETE)
   ├─ node-0:[server] (COMPLETE)
   ├─ node-0:[init_system_keyspaces] (COMPLETE)
   ├─ node-1:[server] (COMPLETE)
   └─ node-2:[server] (COMPLETE)

注意：传递 --json 标记给 status 命令将返回 JSON 应答，其中包含计划的阶段和步骤的 UUID。这些 UUID 对于其他计划命令可能有用。

运行计划

开始

使用 CLI 命令启动计划：

$ dcos cassandra --name=cassandra plan start <plan-name>

暂停

使用提供的阶段名称（或 UUID）暂停计划或该计划中的特定阶段。

$ dcos cassandra --name=cassandra plan pause <plan (required)> <phase (optional)>

停止

使用提供的名称停止运行中的计划。

$ dcos cassandra --name=cassandra plan stop <plan>

计划停止与计划暂停不同，区别如下：

可以为计划中的特定阶段或所有阶段发出暂停。只能为计划发出停止。
暂停更新基础的阶段/步骤状态。停止既是停止执行，也停止计划，并将计划重置为初始待定状态。

恢复

使用提供的阶段名称（或 UUID）恢复计划或该计划的特定阶段。

$ dcos cassandra --name=cassandra plan resume <plan (required)> <phase (optional)>

强制重启

重新启动指定的步骤、阶段（如果未指定步骤）或计划（如果未指定阶段）。

$ dcos cassandra --name=cassandra force-restart <plan (required)> <phase (optional)> <step (optional)>

强制完成

强制完成计划中所提供阶段的特定步骤。通过 CLI，只能强制完成一个步骤。HTTP API 支持强制整体完成各个阶段和计划。

$ dcos cassandra --name=cassandra force-complete <plan (required)> <phase (required)> <step (required)>

Pod 操作

已部署的 DC/OS Apache Cassandra 服务实例由一组运行中的 Pod 组成。使用 pod API 可以管理这些 Pod 的生命周期，以及调查 Pod 及其任务的故障。

注意： 管理 Pod 计数通过服务配置完成，没有直接 API。

列表

要列出服务的所有 Pod，运行 CLI 命令：

$ dcos cassandra --name=cassandra pod list

状态

要查看所有 Pod 的状态，或者选择查看一个 Pod 的状态，运行 CLI 命令：

$ dcos cassandra --name=cassandra pod <pod-name (optional)>

这将显示 Pod 及其任务的任何状态覆盖。

重新启动

要重新启动 Pod，使用 CLI 命令：

$ dcos cassandra --name=cassandra pod restart <pod-name>

这将终止 Pod 的任务并将其重新启动到位。重新启动的进度可通过查看服务的 recovery 计划进行监控。

替换

仅当 Pod 当前实例应该被完全销毁时，才能使用替换。Pod 的所有持久数据（读取：卷）将被销毁。在移除 DC/OS 代理、永久停工或需要更新 Pod 布局约束时应使用替换。

通过运行 CLI 命令发出替换：

$ dcos cassandra --name=cassandra pod replace <pod-name>

暂停

暂停 Pod 会以空闲命令状态将其重新启动。这允许您调试 Pod 的内容，可能会进行更改以修补问题，同时仍可以访问 Pod 的所有上下文（如卷）

使用暂停和 dcos task exec 是非常强大的调试工具。要暂停 Pod，使用 CLI 命令：

$ dcos cassandra --name=cassandra debug pod pause <pod-name>

要暂停 Pod 的特定任务，附加“-t” ` 标记，

$ dcos cassandra --name=cassandra debug pod pause <pod-name> -t <task-name>

使用 pod status 命令以检查哪些任务和 Pod 处于覆盖状态。

恢复

要恢复暂停的 Pod 或任务，使用 CLI 命令：

$ dcos cassandra --name=cassandra debug pod resume <pod-name> [-t <task-name>]

检查 pod status 命令以验证是否已正确恢复 Pod（或任务）。

服务度量标准

DC/OS Apache Cassandra 服务将度量标准推送到 DC/OS 度量标准系统。有关其使用情况的详细信息可参阅 DC/OS 度量标准系统文档。

记录

DC/OS 有三种访问服务调度程序和服务任务日志的方法。

通过 DC/OS GUI
通过 Mesos GUI
通过 DC/OS CLI

DC/OS GUI

通过在服务选项卡中选择服务，可访问服务日志。在此视图中，服务调度程序和服务任务并排显示。要查看任务沙盒（文件）及其 stdout 和 stderr，单击任务。

Mesos GUI

Mesos GUI 提供与 DC/OS UI 相似的访问，但服务调度程序与服务任务分开。所有服务任务均可在与服务名称相同的框架下的框架选项卡中找到。服务调度程序可在 Marathon 框架中找到，它是与服务名称相同的任务。

单击 sandbox 链接可访问服务的文件和日志。

DC/OS CLI

这里的 dcos task log 子命令允许您同时从多个任务中拉取日志。`dcos task log ”命令将获取与前缀模式匹配的所有任务的日志。有关子命令的完整详细信息，请参阅该子命令的帮助。

Mesos 代理日志

有时候，检查给定的 Mesos 代理节点正在做什么也很有用。Mesos 代理节点处理在集群中在给定物理系统中部署 Mesos 任务。每个系统上运行一个 Mesos 代理节点。这些日志可用于确定是否存在系统级别的导致该系统上跨多个服务的警报的问题。

Mesos 代理节点日志可通过 Mesos GUI 或直接在代理上访问。此处描述了 GUI 方法。

在查看任务时，单击面包屑导航中的“代理”项目直接从任务导航至要查看的代理（这将直接转到运行该任务的代理），或者通过在屏幕顶部的“代理”菜单项目导航（您需要从列表中选择所需的代理）。

在代理视图中，您将看到在该代理上出现的框架的列表。在左侧窗格中，您将看到名为“LOG”的普通链接。点击该链接查看代理日志。

执行 Cassandra 清理和修复操作

您可以使用 CLI 或 HTTP API 来对 Cassandra 实例手动触发某些 nodetool 操作。

清理

您可以使用 cleanup 计划在 Cassandra 节点中触发 nodetool cleanup 操作。此计划要求运行以下参数：

CASSANDRA_KEYSPACE：要清理的 Cassandra keyspace。

从命令行启动此计划：

dcos cassandra --name=<service-name> plan start cleanup -p CASSANDRA_KEYSPACE=space1

要从命令行查看此计划的状态：

dcos cassandra --name=<service-name> plan status cleanup
cleanup (IN_PROGRESS)
└─ cleanup-deploy (IN_PROGRESS)
├─ node-0:[cleanup] (COMPLETE)
├─ node-1:[cleanup] (STARTING)
└─ node-2:[cleanup] (PENDING)

计划完成后，其状态将为 COMPLETE。

上述 plan start 和 plan status 命令也可以通过 HTTP 直接发送给服务。要查看涉及的查询，请运行上述具有附加 -v 标记的命令。

如需有关 nodetool cleanup 的更多信息，请查阅 Cassandra 文档。

修复

您可以使用 repair 计划在 Cassandra 节点中触发 nodetool repair 操作。此计划要求运行以下参数：

CASSANDRA_KEYSPACE：要清理的 Cassandra keyspace。

要从命令行启动此命令：

dcos cassandra --name=<service-name> plan start repair -p CASSANDRA_KEYSPACE=space1

要从命令行查看此计划的状态：

dcos cassandra --name=<service-name> plan status repair
repair (STARTING)
└─ repair-deploy (STARTING)
   ├─ node-0:[repair] (STARTING)
   ├─ node-1:[repair] (PENDING)
   └─ node-2:[repair] (PENDING)

计划完成后，其状态将为 COMPLETE。

上述 plan start 和 plan status 命令也可以通过 HTTP 直接发送给服务。要查看涉及的查询，请运行上述具有附加 -v 标记的命令。

如需有关 nodetool repair 的更多信息，请查阅 Cassandra 文档。

种子节点

Cassandra 种子节点是指指数小于种子节点计数的节点。默认情况下，Cassandra 已部署种子节点计数为两个（节点-0 和节点-1 为种子节点）。当对这些节点执行更换操作时，必须重新启动所有其他节点，才能更新为新种子节点的 IP 地址。该操作自动执行。

例如，如果 node-0 需要更换，那么您将执行：

dcos cassandra --name=<service-name> pod replace node-0

这会导致如下恢复计划：

$ dcos cassandra --name=<service-name> plan show recovery
recovery (IN_PROGRESS)
└─ permanent-node-failure-recovery (IN_PROGRESS)
   ├─ node-0:[server] (COMPLETE)
   ├─ node-1:[server] (STARTING)
   └─ node-2:[server] (PENDING)
   ...

注意： 只有种子节点被放置在新节点上，所有其他节点都会被重新启动，而不会丢失数据。

备份和恢复

备份至 S3

可以使用 backup-s3 计划将整个集群的数据和架构备份到 Amazon S3。此计划要求运行以下参数：

SNAPSHOT_NAME：此快照的名称。单个节点的快照会储存到顶层 snapshot 文件夹中的 S3 文件夹。
CASSANDRA_KEYSPACES：要备份的 Cassandra keyspace。会按照每个指定的 keyspaces 备份整个 keyspace 及其架构。
AWS_ACCESS_KEY_ID：运行此备份的 AWS IAM 用户的访问密钥 ID
AWS_SECRET_ACCESS_KEY：运行此备份的 AWS IAM 用户的秘密访问密钥
AWS_REGION：用于存储此备份的 S3 bucket 区域
S3_BUCKET_NAME：存储此备份的 S3 bucket 的名称

确保为您的节点配置足够的磁盘空间来执行备份。Apache Cassandra 备份在上传到 S3 之前存储在磁盘上，并且占用的空间和当前表中的数据一样多，所以您需要有一半的总可用空间，以一次备份每个 keyspace。

如备份/恢复策略配置选项文档中所述，可以串行或并行传输至 S3，但必须小心不要超过集群中可能存在的任何吞吐量限制。吞吐量取决于多种因素，包括上行链路速度、与正在上传和下载备份的区域的接近度以及底层存储基础架构的性能。您应在当地环境中定期进行测试，以了解您可以从 S3 获得什么。

您可以配置快照是串行（默认）还是并行进行创建和上传。建议使用串行备份/恢复策略。

您可以从命令行启动此计划：

SNAPSHOT_NAME=<my_snapshot>
CASSANDRA_KEYSPACES="space1 space2"
AWS_ACCESS_KEY_ID=<my_access_key_id>
AWS_SECRET_ACCESS_KEY=<my_secret_access_key>
AWS_REGION=us-west-2
S3_BUCKET_NAME=backups
dcos cassandra --name=<service-name> plan start backup-s3 \
    -p SNAPSHOT_NAME=$SNAPSHOT_NAME \
    -p "CASSANDRA_KEYSPACES=$CASSANDRA_KEYSPACES" \
    -p AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID \
    -p AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY \
    -p AWS_REGION=$AWS_REGION \
    -p S3_BUCKET_NAME=$S3_BUCKET_NAME

如果您要备份多个 keyspace，它们必须以空格进行分隔，并在提供给 plan start 命令时加上引号，如上例所示。如果 CASSANDRA_KEYSPACES 参数未提供，那么您集群中的每个 keyspace 都将被备份。

警告：为确保敏感信息（例如，您的 AWS 秘密访问密钥）处于安全状态，确保您已将 DC/OS CLI 中的 core.dcos_url 配置属性设置到 HTTPS URL。

要从命令行查看此计划的状态：

dcos cassandra --name=<service-name> plan status backup-s3
backup-s3 (IN_PROGRESS)
├─ backup-schema (COMPLETE)
│  ├─ node-0:[backup-schema] (COMPLETE)
│  ├─ node-1:[backup-schema] (COMPLETE)
│  └─ node-2:[backup-schema] (COMPLETE)
├─ create-snapshots (IN_PROGRESS)
│  ├─ node-0:[snapshot] (STARTED)
│  ├─ node-1:[snapshot] (STARTED)
│  └─ node-2:[snapshot] (COMPLETE)
├─ upload-backups (PENDING)
│  ├─ node-0:[upload-s3] (PENDING)
│  ├─ node-1:[upload-s3] (PENDING)
│  └─ node-2:[upload-s3] (PENDING)
└─ cleanup-snapshots (PENDING)
   ├─ node-0:[cleanup-snapshot] (PENDING)
   ├─ node-1:[cleanup-snapshot] (PENDING)
   └─ node-2:[cleanup-snapshot] (PENDING)

上述 plan start 和 plan status 命令也可以通过 HTTP 直接发送给服务。要查看涉及的查询，请运行上述具有附加 -v 标记的命令。

备份至 Azure

您还可以使用 backup-azure 计划来备份至 Microsoft Azure。此计划要求运行以下参数：

SNAPSHOT_NAME：此快照的名称。单个节点的快照会存储为使用 gzip 压缩的 tarball，名称为 node-<POD_INDEX>.tar.gz。
CASSANDRA_KEYSPACES：要备份的 Cassandra keyspace。会按照每个指定的 keyspaces 备份整个 keyspace 及其架构。
CLIENT_ID：运行此备份的 Azure 服务主体的客户端 ID
TENANT_ID：服务主体所属租户的租户 ID
CLIENT_SECRET：服务主体的秘密密钥
AZURE_STORAGE_ACCOUNT：此备份将发送到的存储帐户的名称
AZURE_STORAGE_KEY：与存储帐户关联的密钥
CONTAINER_NAME：存储此备份的容器的名称

您可以按照与 Amazon S3 备份计划相同的方式从命令行启动此计划：

dcos cassandra --name=<service-name> plan start backup-azure \
    -p SNAPSHOT_NAME=$SNAPSHOT_NAME \
    -p "CASSANDRA_KEYSPACES=$CASSANDRA_KEYSPACES" \
    -p CLIENT_ID=$CLIENT_ID \
    -p TENANT_ID=$TENANT_ID \
    -p CLIENT_SECRET=$CLIENT_SECRET \
    -p AZURE_STORAGE_ACCOUNT=$AZURE_STORAGE_ACCOUNT \
    -p AZURE_STORAGE_KEY=$AZURE_STORAGE_KEY \
    -p CONTAINER_NAME=$CONTAINER_NAME

要从命令行查看此计划的状态：

dcos cassandra --name=<service-name> plan status backup-azure
backup-azure (IN_PROGRESS)
├─ backup-schema (COMPLETE)
│  ├─ node-0:[backup-schema] (COMPLETE)
│  ├─ node-1:[backup-schema] (COMPLETE)
│  └─ node-2:[backup-schema] (COMPLETE)
├─ create-snapshots (COMPLETE)
│  ├─ node-0:[snapshot] (COMPLETE)
│  ├─ node-1:[snapshot] (COMPLETE)
│  └─ node-2:[snapshot] (COMPLETE)
├─ upload-backups (IN_PROGRESS)
│  ├─ node-0:[upload-azure] (COMPLETE)
│  ├─ node-1:[upload-azure] (STARTING)
│  └─ node-2:[upload-azure] (PENDING)
└─ cleanup-snapshots (PENDING)
   ├─ node-0:[cleanup-snapshot] (PENDING)
   ├─ node-1:[cleanup-snapshot] (PENDING)
   └─ node-2:[cleanup-snapshot] (PENDING)

上述 plan start 和 plan status 命令也可以通过 HTTP 直接发送给服务。要查看涉及的查询，请运行上述具有附加 -v 标记的命令。

恢复

所有恢复计划都将从备份计划备份的每个 keyspace 恢复架构，并使用拍摄快照时所包含的数据填充这些 keyspace。下载和恢复备份将使用配置的备份/恢复策略。此计划假设当前集群中不存在正在恢复的 keyspace，并且如果存在任何同名的 keyspace，则将失败。

从 S3 进行恢复

恢复集群数据类似于进行备份。 restore-s3 计划假设您的数据以 backup-s3 所使用的格式存储在 S3 bucket 中。恢复计划具有以下参数：

SNAPSHOT_NAME：backup-s3 计划中的快照名称
AWS_ACCESS_KEY_ID：运行此恢复的 AWS IAM 用户的访问密钥 ID
AWS_SECRET_ACCESS_KEY：运行此恢复的 AWS IAM 用户的秘密访问密钥
AWS_REGION：用于存储正在恢复的备份的 S3 bucket 区域
S3_BUCKET_NAME：存储备份的 S3 bucket 的名称

从命令行启动此计划：

SNAPSHOT_NAME=<my_snapshot>
CASSANDRA_KEYSPACES="space1 space2"
AWS_ACCESS_KEY_ID=<my_access_key_id>
AWS_SECRET_ACCESS_KEY=<my_secret_access_key>
AWS_REGION=us-west-2
S3_BUCKET_NAME=backups
dcos cassandra --name=<service-name> plan start restore-s3 \
    -p SNAPSHOT_NAME=$SNAPSHOT_NAME \
    -p "CASSANDRA_KEYSPACES=$CASSANDRA_KEYSPACES" \
    -p AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID \
    -p AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY \
    -p AWS_REGION=$AWS_REGION \
    -p S3_BUCKET_NAME=$S3_BUCKET_NAME

要从命令行查看此计划的状态：

dcos cassandra --name=<service-name> plan status restore-s3
restore-s3 (IN_PROGRESS)
├─ fetch-s3 (COMPLETE)
│  ├─ node-0:[fetch-s3] (COMPLETE)
│  ├─ node-1:[fetch-s3] (COMPLETE)
│  └─ node-2:[fetch-s3] (COMPLETE)
├─ restore-schema (IN_PROGRESS)
│  ├─ node-0:[restore-schema] (COMPLETE)
│  ├─ node-1:[restore-schema] (STARTED)
│  └─ node-2:[restore-schema] (PENDING)
└─ restore-snapshots (PENDING)
   ├─ node-0:[restore-snapshot] (PENDING)
   ├─ node-1:[restore-snapshot] (PENDING)
   └─ node-2:[restore-snapshot] (PENDING)

上述 plan start 和 plan status 命令也可以通过 HTTP 直接发送给服务。要查看涉及的查询，请运行上述具有附加 -v 标记的命令。

从 Azure 进行恢复

您可以使用 restore-azure 计划从 Microsoft Azure 进行恢复。此计划要求运行以下参数：

SNAPSHOT_NAME：此快照的名称。单个节点的快照会存储为使用 gzip 压缩的 tarball，名称为 node-<POD_INDEX>.tar.gz。
CLIENT_ID：运行此备份的 Azure 服务主体的客户端 ID
TENANT_ID：服务主体所属租户的租户 ID
CLIENT_SECRET：服务主体的秘密密钥
AZURE_STORAGE_ACCOUNT：此备份将发送到的存储帐户的名称
AZURE_STORAGE_KEY：与存储帐户关联的密钥
CONTAINER_NAME：存储此备份的容器的名称

您可以按照与 Amazon S3 恢复计划相同的方式从命令行启动此计划：

dcos cassandra --name=<service-name> plan start restore-azure \
    -p SNAPSHOT_NAME=$SNAPSHOT_NAME \
    -p CLIENT_ID=$CLIENT_ID \
    -p TENANT_ID=$TENANT_ID \
    -p CLIENT_SECRET=$CLIENT_SECRET \
    -p AZURE_STORAGE_ACCOUNT=$AZURE_STORAGE_ACCOUNT \
    -p AZURE_STORAGE_KEY=$AZURE_STORAGE_KEY \
    -p CONTAINER_NAME=$CONTAINER_NAME

要从命令行查看此计划的状态：

dcos cassandra --name=<service-name> plan status restore-azure
restore-azure (IN_PROGRESS)
├─ fetch-azure (COMPLETE)
│  ├─ node-0:[fetch-azure] (COMPLETE)
│  ├─ node-1:[fetch-azure] (COMPLETE)
│  └─ node-2:[fetch-azure] (COMPLETE)
├─ restore-schema (COMPLETE)
│  ├─ node-0:[restore-schema] (COMPLETE)
│  ├─ node-1:[restore-schema] (COMPLETE)
│  └─ node-2:[restore-schema] (COMPLETE)
└─ restore-snapshots (IN_PROGRESS)
   ├─ node-0:[restore-snapshot] (COMPLETE)
   ├─ node-1:[restore-snapshot] (STARTING)
   └─ node-2:[restore-snapshot] (PENDING)

上述 plan start 和 plan status 命令也可以通过 HTTP 直接发送给服务。要查看涉及的查询，请运行上述具有附加 -v 标记的命令。

运维

管理 Cassandra

计划操作

列表计划

检查计划

运行计划

开始

暂停

停止

恢复

强制重启

强制完成

Pod 操作

列表

状态

重新启动

替换

暂停

恢复

服务度量标准

记录

DC/OS GUI

Mesos GUI

DC/OS CLI

Mesos 代理日志

执行 Cassandra 清理和修复操作

清理

修复

种子节点

备份和恢复

备份至 S3

备份至 Azure

恢复

从 S3 进行恢复

从 Azure 进行恢复