Azure 门户中 Azure 认知搜索服务管理Service administration for Azure Cognitive Search in the Azure portal

Azure 认知搜索是一种完全托管的、基于云的搜索服务,用于在自定义应用中生成丰富的搜索体验。Azure Cognitive Search is a fully managed, cloud-based search service used for building a rich search experience into custom apps. 本文介绍可在 Azure 门户中对已预配的搜索服务执行的服务管理任务。This article covers the service administration tasks that you can perform in the Azure portal for a search service that you've already provisioned. 服务管理设计成轻型,它限于以下任务:Service administration is lightweight by design, limited to the following tasks:

  • 管理对用于服务读取或写入的 api-keys 的访问。Manage access to the api-keys used for read or write access to your service.
  • 通过更改分区和副本的分配以调整服务容量。Adjust service capacity by changing the allocation of partitions and replicas.
  • 根据服务层级的最大限制,监视资源使用情况。Monitor resource usage, relative to maximum limits of your service tier.

请注意,“升级” 未列为管理任务。Notice that upgrade is not listed as an administrative task. 因为预配服务时会分配资源,所以移动到其他层需要新的服务。Because resources are allocated when the service is provisioned, moving to a different tier requires a new service. 有关详细信息,请参阅创建 Azure 认知搜索服务For details, see Create an Azure Cognitive Search service.

可以监视查询量和其他指标,并根据这些见解调整自己的服务以缩短响应时间。You can monitor query volume and other metrics, and use those insights to adjust your service for faster response times. 有关详细信息,请参阅监视使用情况和查询度量值以及性能和优化For more information, see Monitor usage and query metrics and Performance and optimization.

管理员权限Administrator rights

预配或解除对服务本身的授权可以通过 Azure 订阅管理员或协同管理员完成。Provisioning or decommissioning the service itself can be done by an Azure subscription administrator or co-administrator.

在服务中,有权访问服务 URL 并拥有管理员 API 密钥的任何人都有对该服务的读写访问权限。Within a service, anyone with access to the service URL and an admin api-key has read-write access to the service. 借助读写访问权限能够添加、删除或修改服务器对象(包括通过 RBAC 定义的角色实现的 API 密钥、索引、索引器、数据源、计划和角色分配)。Read-write access provides the ability to add, delete, or modify server objects, including api-keys, indexes, indexers, data sources, schedules, and role assignments as implemented through RBAC-defined roles.

Azure 认知搜索服务的所有用户交互属于下列模式之一:对服务的读写访问(管理员权限)或对服务的只读访问(查询权限)。All user interaction with Azure Cognitive Search falls within one of these modes: read-write access to the service (administrator rights), or read-only access to the service (query rights). 有关详细信息,请参阅管理 API 密钥For more information, see Manage the api-keys.

日志记录和系统信息Logging and system information

Azure 认知搜索服务不会通过门户或程序设计界面公开单个服务的日志文件。Azure Cognitive Search does not expose log files for an individual service either through the portal or programmatic interfaces. 在基本层以及更高层上,Microsoft 会监视所有 Azure 认知搜索服务以达到服务级别协议 (SLA) 的 99.9% 可用性。At the Basic tier and above, Microsoft monitors all Azure Cognitive Search services for 99.9% availability per service level agreements (SLA). 如果服务的速度较慢或请求吞吐量低于 SLA 阈值,则支持团队审查提供给他们的日志文件并解决问题。If the service is slow or request throughput falls below SLA thresholds, support teams review the log files available to them and address the issue.

根据服务的常规信息,可以通过以下方式获取信息:In terms of general information about your service, you can obtain information in the following ways:

监视资源使用情况Monitor resource usage

在仪表板中,资源监视仅限于服务仪表板中显示的信息,以及一些可通过查询服务获得的度量值。In the dashboard, resource monitoring is limited to the information shown in the service dashboard and a few metrics that you can obtain by querying the service. 在服务仪表板的“使用量”部分中,可以快速确定分区资源级别是否适合应用程序。On the service dashboard, in the Usage section, you can quickly determine whether partition resource levels are adequate for your application. 如果你希望捕获并持久保存所记录的事件,可以预配外部资源,例如 Azure 监视。You can provision external resources, such as Azure monitoring, if you want to capture and persist logged events. 有关详细信息,请参阅监视 Azure 认知搜索For more information, see Monitoring Azure Cognitive Search.

使用搜索服务 REST API,可以通过编程方式获取文档和索引的计数:Using the search service REST API, you can get a count on documents and indexes programmatically:

灾难恢复和服务中断Disaster recovery and service outages

虽然我们可以挽救数据,但 Azure 认知搜索在群集或数据中心级别发生服务中断时不提供服务的即时故障转移。Although we can salvage your data, Azure Cognitive Search does not provide instant failover of the service if there is an outage at the cluster or data center level. 如果数据中心的群集出现故障,运营团队会检测故障,并努力还原服务。If a cluster fails in the data center, the operations team will detect and work to restore service. 在服务还原期间将遇到停机,但是可以根据服务级别协议 (SLA) 申请服务信用额度来补偿服务不可用的情况。You will experience downtime during service restoration, but you can request service credits to compensate for service unavailability per the Service Level Agreement (SLA).

如果在超出 Microsoft 控制的灾难性故障中需要连续性服务,可在其他区域预配一个附加服务并实施异地复制策略,确保索引跨所有服务完全冗余。If continuous service is required in the event of catastrophic failures outside of Microsoft’s control, you could provision an additional service in a different region and implement a geo-replication strategy to ensure indexes are fully redundant across all services.

使用索引器来填充和刷新索引的客户可利用相同的数据源,通过特定于地区的索引器来处理灾难恢复。Customers who use indexers to populate and refresh indexes can handle disaster recovery through geo-specific indexers leveraging the same data source. 不同区域的两个服务(每个都运行索引器)可对相同数据源进行索引,实现异地冗余。Two services in different regions, each running an indexer, could index the same data source to achieve geo-redundancy. 如果从同样异地冗余的数据源进行索引,请注意 Azure 认知搜索索引器只能从主要副本执行增量索引(从新的、已修改的或已删除的文档合并更新)。If you are indexing from data sources that are also geo-redundant, be aware that Azure Cognitive Search indexers can only perform incremental indexing (merging updates from new, modified, or deleted documents) from primary replicas. 在故障转移事件中,请确保将索引器重新指向到新的主要副本。In a failover event, be sure to re-point the indexer to the new primary replica.

如果不使用索引器,也可使用应用程序代码将对象和数据并行推送到其他搜索服务。If you do not use indexers, you would use your application code to push objects and data to different search services in parallel. 有关详细信息,请参阅 Azure 认知搜索中的性能和优化For more information, see Performance and optimization in Azure Cognitive Search.

备份和还原Backup and restore

由于 Azure 认知搜索不是主数据存储解决方案,因此,我们不提供正式的自助备份和还原机制。Because Azure Cognitive Search is not a primary data storage solution, we do not provide a formal mechanism for self-service backup and restore. 但是,你可以使用此 Azure 认知搜索 .NET 示例存储库中的 index-backup-restore 示例代码将索引定义和快照备份到一系列 JSON 文件,然后根据需要使用这些文件来还原索引。However, you can use the index-backup-restore sample code in this Azure Cognitive Search .NET sample repo to backup your index definition and snapshot to a series of JSON files, and then use these files to restore the index, if needed. 还可以使用此工具在服务层级之间移动索引。This tool can also move indexes between service tiers.

在其他情况下,如果误删索引,用于创建和填充索引的应用程序代码是事实上的还原选项。Otherwise, your application code used for creating and populating an index is the de facto restore option if you delete an index by mistake. 要重新生成索引,请删除它(假设其存在),在服务中重新创建该索引,并通过从主数据存储中检索数据来重新加载该索引。To rebuild an index, you would delete it (assuming it exists), recreate the index in the service, and reload by retrieving data from your primary data store.

增加或减少Scale up or down

每个搜索服务从至少一个副本和一个分区开始操作。Every search service starts with a minimum of one replica and one partition. 如果已注册提供专用资源的层,请单击服务仪表板中的“规模”磁贴,调整资源使用情况 。If you signed up for a tier that provides dedicated resources, click the SCALE tile in the service dashboard to adjust resource usage.

如果通过任一资源添加容量,服务会自动使用它们。When you add capacity through either resource, the service uses them automatically. 无需执行任何进一步的操作,但在新资源产生作用之前,会有轻微延迟。No further action is required on your part, but there is a slight delay before the impact of the new resource is realized. 可能需要 15 分钟或更长的时间才能预配其他资源。It can take 15 minutes or more to provision additional resources.

添加副本Add replicas

增加每秒查询次数 (QPS) 或实现高可用性可通过添加副本来完成。Increasing queries per second (QPS) or achieving high availability is done by adding replicas. 每个副本都有索引的副本,因此多添加一个副本将转换为可用于处理服务查询要求的多个索引。Each replica has one copy of an index, so adding one more replica translates to one more index available for handling service query requests. 高可用性至少需要 3 个副本(有关详细信息,请参阅容量规划)。A minimum of 3 replicas are required for high availability (see Capacity Planning for details).

具有许多副本的搜索服务可通过大量索引进行负载均衡查询请求。A search service having more replicas can load balance query requests over a larger number of indexes. 在给定查询量级别的情况下,当有更多索引副本可用于为请求提供服务时,查询吞吐量的速度将更快。Given a level of query volume, query throughput is going to be faster when there are more copies of the index available to service the request. 如果出现查询延迟,会期望在附加副本联机后对性能产生积极的影响。If you are experiencing query latency, you can expect a positive impact on performance once the additional replicas are online.

尽管添加副本时查询吞吐量会提高,但不会按在将向服务添加副本时的恰好两倍或三倍来提高。Although query throughput goes up as you add replicas, it does not precisely double or triple as you add replicas to your service. 所有搜索应用程序都会因可能影响到查询性能的外部因素而受到约束。All search applications are subject to external factors that can impinge on query performance. 复杂的查询和网络延迟是造成查询响应次数变化的两个因素。Complex queries and network latency are two factors that contribute to variations in query response times.

添加分区Add partitions

大多数服务应用程序都有多个副本而非分区方面的内置需求。Most service applications have a built-in need for more replicas rather than partitions. 如果已注册标准服务,则在需要增加文档计数的情况下,可以添加分区。For those cases where an increased document count is required, you can add partitions if you signed up for Standard service. 基本层不提供其他分区。Basic tier does not provide for additional partitions.

在标准层中,分区按 12 的倍数进行添加(具体而言,1、2、3、4、6 或 12)。At the Standard tier, partitions are added in multiples of 12 (specifically, 1, 2, 3, 4, 6, or 12). 这是分片的项目。This is an artifact of sharding. 索引会在 12 个分区中创建,可以全部存储在 1 个分区上,也可以平均分配到 2、3、4、6 或 12 个分区(每个分区一个分片)。An index is created in 12 shards, which can all be stored on 1 partition or equally divided into 2, 3, 4, 6, or 12 partitions (one shard per partition).

删除副本Remove replicas

在高查询量期间过后,可以使用滑块在搜索查询负载正常后(例如,假日销售结束后)减少副本。After periods of high query volumes, you can use the slider to reduce replicas after search query loads have normalized (for example, after holiday sales are over). 无须再执行其他步骤。There are no further steps required on your part. 降低副本计数会消除数据中心内的虚拟机。Lowering the replica count relinquishes virtual machines in the data center. 相较于之前的情况而言,现在会在较少的 VM 上执行查询和数据引入操作。Your query and data ingestion operations will now run on fewer VMs than before. 最低要求是一个副本。The minimum requirement is one replica.

删除分区Remove partitions

与无需执行额外工作即可删除副本相比,如果使用的存储大于可减少的存储,可能需要完成一些工作。In contrast with removing replicas, which requires no extra effort on your part, you might have some work to do if you are using more storage than can be reduced. 例如,如果解决方案使用三个分区,则在新存储空间小于承载索引所需空间时,缩减为一或两个分区将生成错误。For example, if your solution is using three partitions, downsizing to one or two partitions will generate an error if the new storage space is less than required for hosting your index. 正如预期的那样,可以选择删除索引或相关索引内的文档来释放空间,或者保持目前配置。As you might expect, your choices are to delete indexes or documents within an associated index to free up space, or keep the current configuration.

无法通过任何检测方法确定哪些索引分片存储在特定分区上。There is no detection method that tells you which index shards are stored on specific partitions. 每个分区提供大约 25 GB 的存储,因此需要将存储减少到可让所拥有分区数能容纳的大小。Each partition provides approximately 25 GB in storage, so you will need to reduce storage to a size that can be accommodated by the number of partitions you have. 如果要还原为一个分区,则所有 12 个分片都需要适合。If you want to revert to one partition, all 12 shards will need to fit.

为了帮助实现未来规划,可能需要检查存储(使用获取索引统计信息),了解实际使用了多少空间。To help with future planning, you might want to check storage (using Get Index Statistics) to see how much you actually used.

后续步骤Next steps

了解服务管理的相关概念后,请考虑使用 PowerShell 来自动执行任务。Once you understand the concepts behind service administration, consider using PowerShell to automate tasks.

同时建议查看性能和优化文章We also recommend reviewing the performance and optimization article.