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:

  • 使用中间页“使用情况”链接检查存储。Check storage using the mid-page Usage link.
  • 使用中间页“监视”链接检查查询量和延迟,以及请求是否受到了限制。Check query volumes and latency using the mid-page Monitoring link, and whether requests were throttled.
  • 使用左边的“密钥”页管理访问。Manage access using the Keys page to the left.
  • 使用左边的“缩放”页调整容量。Adjust capacity using the Scale page to the left.

在门户中执行的相同任务也可以通过管理 APIAz.Search PowerShell 模块以编程方式处理。The same tasks performed in the portal can also be handled programmatically through the Management APIs and Az.Search PowerShell module. 管理任务完全呈现在门户和程序设计界面中。Administrative tasks are fully represented across portal and programmatic interfaces. 任何特定管理任务都不会只能通过一种形式使用。There is no specific administrative task that is available in only one modality.

Azure 认知搜索充分利用其他 Azure 服务进行更深入的监视和管理。Azure Cognitive Search leverages other Azure services for deeper monitoring and management. 通过搜索服务单独存储的唯一数据是内容(索引、索引器和数据源定义,以及其他对象)。By itself, the only data stored with a search service is content (indexes, indexer and data source definitions, and other objects). 报告到门户页面的指标按照滚动的 30 天周期从内部日志中拉取。Metrics reported out to portal pages are pulled from internal logs on a rolling 30-day cycle. 对于用户控制的日志保留和其他事件,需要 Azure MonitorFor user-controlled log retention and additional events, you will need Azure Monitor.

固定的服务属性Fixed service properties

搜索服务的一些方面是在预配服务时确定的,确定后不能更改:Several aspects of a search service are determined when the service is provisioned and cannot be changed later:

  • 服务名称(不能重命名服务)Service name (you cannot rename a service)
  • 服务位置(目前无法将服务原封不动地移动到另一个区域)Service location (you cannot currently move an intact service to another region)
  • 最大副本计数和分区计数(由“基本”层或标准“层”确定)Maximum replica and partition counts (determined by the tier, Basic or Standard)

如果开始时使用的是最大分区数为 1 的“基本”层,并且现在需要多个分区,则需要在更高层创建新服务并在新服务上重新创建内容。If you started with Basic with its maximum of one partition, and you now need more partitions, you will need to create a new service at a higher tier and recreate your content on the new service.

管理员权限Administrator rights

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

关于对终结点的访问,任何具有服务 URL 访问权限和 API 密钥的人员均可访问内容。Regarding access to the endpoint, anyone with access to the service URL and an api-key has access to content. 若要详细了解密钥,请参阅管理 API 密钥For more information about keys, see Manage the api-keys.

  • 服务的只读访问权限是查询权限,通常,向客户端应用程序授予这种权限的方式是向该应用程序提供 URL 和查询 API 密钥。Read-only access to the service is query rights, typically granted to a client application by giving it the URL and a query api-key.
  • 具有读写访问权限就能够添加、删除或修改服务器对象,包括 API 密钥、索引、索引器、数据源和计划。读写访问权限是通过提供 URL 和管理 API 密钥来授予的。Read-write access provides the ability to add, delete, or modify server objects, including api-keys, indexes, indexers, data sources, and schedules.Read-write access is granted by giving the URL, an admin API key.

服务预配设备的权限是通过角色分配授予的。Rights to the service provisioning apparatus is granted through role assignments. 基于角色的访问 (RBAC) 是基于 Azure 资源管理器构建的授权系统,用于预配 Azure 资源。Role-based access (RBAC) is an authorization system built on Azure Resource Manager for provisioning of Azure resources.

在 Azure 认知搜索上下文中,RBAC 角色分配将确定哪些用户可以执行任务,而不考虑他们是使用门户PowerShell 还是管理 REST APIIn the context of Azure Cognitive Search, RBAC role assignments will determine who can perform tasks, regardless of whether they are using the portal, PowerShell, or the Management REST APIs:

  • 创建或删除服务Create or delete a service
  • 缩放服务Scale the service
  • 删除或重新生成 API 密钥Delete or regenerate API keys
  • 启用诊断日志记录(创建服务)Enable diagnostic logging (create services)
  • 启用流量分析(创建服务)Enable traffic analytics (create services)

提示

利用 Azure 范围内的机制,可以锁定订阅或资源,以防止具备管理员权限的用户意外或在未经授权的情况下删除搜索服务。Using Azure-wide mechanisms, you can lock a subscription or resource to prevent accidental or unauthorized deletion of your search service by users with admin rights. 有关详细信息,请参阅锁定资源以防止意外删除For more information, see Lock resources to prevent unexpected deletion.

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

在基本层以及更高层上,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.

Azure 认知搜索利用 Azure Monitor 来收集和存储索引及查询活动。Azure Cognitive Search leverages Azure Monitor to collect and store indexing and query activity. 搜索服务仅单独存储其内容(索引、索引器定义、数据源定义、技能组定义、同义词映射)。A search service by itself stores just its content (indexes, indexer definitions, data source definitions, skillset definitions, synonym maps). 高速缓存信息和记录的信息是脱离服务而存储的,通常存储在 Azure 存储帐户中。Caching and logged information is stored off-service, often in an Azure Storage account. 有关记录索引和查询工作负载的详细信息,请参阅收集和分析日志数据For more information about logging indexing and query workloads, see Collect and analyze log data.

就有关服务的一般信息而言,只需使用 Azure 认知搜索本身内置的设施就可以通过以下方式获取信息:In terms of general information about your service, using just the facilities built into Azure Cognitive Search itself, you can obtain information in the following ways:

  • 使用服务“概述”页面,通过通知、属性和状态消息。Using the service Overview page, through notifications, properties, and status messages.
  • 使用 PowerShell管理 REST API获取服务属性Using PowerShell or the Management REST API to get service properties. 在编程层不提供新信息或操作。There is no new information or operations provided at the programmatic layer. 接口是存在的,这样你便可以编写脚本。The interfaces exist so that you can write scripts.

监视资源使用情况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 supports more capacity, click Scale on the left navigation pane 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 Adjust capacity 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

添加副本更为常见,但当存储受到限制时,你可以添加分区以获得更多容量。It's more common to add replicas, but when storage is constrained, you can add partitions to get more capacity. 预配服务的层确定是否可以添加分区。The tier at which you provisioned the service determines whether partitions can be added. 基本层锁定在一个分区上。The Basic tier is locked at one partition. 标准层及以上层支持其他数量的分区。Standard tiers and above support additional partitions.

分区数按 12 的因数进行添加(具体而言为 1、2、3、4、6 或 12)。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