一、背景说明 Knox + Kerberos

在 Atlas 的最小化安装流程中，SolrCloud 初始化通常是直连 Solr Admin API（8983） 来完成的。 但当集群已经安装并启用了 Knox 服务后，Solr 会被 Knox Gateway 统一代理包装，外部（或客户端侧）访问 Solr 的入口不再是 8983，而是 Knox 的代理路径。

我们在 Knox 服务侧可以看到 Solr 已被纳入 Gateway 管理：

因此，Solr 的访问路径需要切换为：

https://dev1:6543/gateway/default/solr/

为什么“步骤不变，但关键点不一样”

最小化安装的核心动作仍然是两件事：

1. 上传 Atlas Solr ConfigSet（atlas schema/config）
2. 创建 Atlas 三大 Collection（vertex/edge/fulltext）

区别在于：

• 未开启 Kerberos：直接访问 http://<solr>:8983/solr/...
• 开启 Kerberos + Knox：通过 https://<knox>:6543/gateway/default/solr/... 代理访问，并需要具备可用的认证信息

二、解决办法 Solr 初始化

1、Kerberos 凭证准备（p0）

开启 Kerberos 后，建议在执行初始化前先准备好可用的 Kerberos 凭证（避免命令执行到一半才发现票据无效）。

kdestroy || true

kinit -kt /etc/security/keytabs/smokeuser.headless.keytab \
  [email protected]

klist

上述 principal 与 keytab 在哪里确认？ 可以从 Ambari 的 Kerberos 凭证管理页确认（必要时下载 CSV 对照主机对应的 principal）：

实用建议

这里不需要额外创建专用用户，直接使用集群已有的 smokeuser 或运维用户即可。 只要该 principal 在 Kafka/HDFS/Knox 等链路里具备必要权限，后续验证会更顺畅。

2、打包 Atlas Solr ConfigSet

Atlas 自带的 Solr 配置位于 Atlas Server 安装目录中，通常路径为：

/usr/bigtop/current/atlas-server/conf/solr

执行打包：

cd /usr/bigtop/current/atlas-server/conf/solr
zip -r /tmp/atlas-solr-conf.zip .

为什么要打包 ConfigSet

SolrCloud 的 collection 通常引用 configset。 Atlas 的三大 collection（vertex/edge/fulltext）都需要同一套 schema/config，因此推荐先上传名为 atlas 的 configset，再创建 collection 时引用它。

3、上传 ConfigSet（未开启 / 已开启 Kerberos 对比）

curl -X POST -H "Content-Type: application/octet-stream" \
  --data-binary @/tmp/atlas-solr-conf.zip \
  "http://dev1:8983/solr/admin/configs?action=UPLOAD&name=atlas&wt=json"

curl -k -u admin:admin-password \
  -X POST \
  -H "Content-Type: application/octet-stream" \
  --data-binary @/tmp/atlas-solr-conf.zip \
  "https://dev1:6543/gateway/default/solr/admin/configs?action=UPLOAD&name=atlas&wt=json"

// Make sure to add code blocks to your code group

常见误区

很多人会在开启 Knox 后仍然去请求 http://dev1:8983/solr/...，结果表现为：

• 连接超时/拒绝（端口未开放或仅内网可达）
• 上传成功但 Atlas 侧仍不可用（Atlas 走的是 Knox 代理链路）

只要 Solr 被 Knox 包装，初始化动作就应该统一走 gateway/default/solr 的路径。

4、创建 Atlas 三大 Collection

Atlas 依赖三大 collection，它们分别用于顶点、边关系与全文索引：

Collection	作用	Atlas 影响点
vertex_index	顶点索引	实体/属性检索的基础
edge_index	边关系索引	血缘、关系查询
fulltext_index	全文索引	关键字搜索与模糊匹配

curl "http://dev1:8983/solr/admin/collections?action=CREATE&name=vertex_index&numShards=1&replicationFactor=1&collection.configName=atlas&wt=json&zkHost=dev1:2181,dev2:2181,dev3:2181/solr"

curl "http://dev1:8983/solr/admin/collections?action=CREATE&name=edge_index&numShards=1&replicationFactor=1&collection.configName=atlas&wt=json&zkHost=dev1:2181,dev2:2181,dev3:2181/solr"

curl "http://dev1:8983/solr/admin/collections?action=CREATE&name=fulltext_index&numShards=1&replicationFactor=1&collection.configName=atlas&wt=json&zkHost=dev1:2181,dev2:2181,dev3:2181/solr"

curl -k -u admin:admin-password \
  "https://dev1:6543/gateway/default/solr/admin/collections?action=CREATE&name=vertex_index&numShards=1&replicationFactor=1&collection.configName=atlas&wt=json"

curl -k -u admin:admin-password \
  "https://dev1:6543/gateway/default/solr/admin/collections?action=CREATE&name=edge_index&numShards=1&replicationFactor=1&collection.configName=atlas&wt=json"

curl -k -u admin:admin-password \
  "https://dev1:6543/gateway/default/solr/admin/collections?action=CREATE&name=fulltext_index&numShards=1&replicationFactor=1&collection.configName=atlas&wt=json"

// Make sure to add code blocks to your code group

参数怎么取舍

最小化安装阶段常用 numShards=1、replicationFactor=1，先确保链路打通。 后续如果做高可用与容量规划，可以再根据 SolrCloud 集群规模调整 shard/replica。

三、结果验证 LIST 校验

1、验证 Collection 是否创建成功（直连 / Knox 对比）

curl "http://dev1:8983/solr/admin/collections?action=LIST&wt=json"

curl -k -u admin:admin-password \
  "https://dev1:6543/gateway/default/solr/admin/collections?action=LIST&wt=json"

// Make sure to add code blocks to your code group

返回结果中应包含：

[
  "vertex_index",
  "edge_index",
  "fulltext_index"
]

验证通过后的含义

当这三个 collection 都存在时，Atlas 的 Solr 索引端已经具备最小可用条件。 后续 Atlas Server 启动时，JanusGraph 的索引后端（Solr）初始化与查询链路会明显更稳定。