Szolgáltatás-felügyelet az Azure Cognitive Search a Azure PortalService administration for Azure Cognitive Search in the Azure portal

Az Azure Cognitive Search egy teljes körűen felügyelt, felhőalapú keresési szolgáltatás, amellyel gazdag keresési élményt hozhat létre egyéni alkalmazásokba.Azure Cognitive Search is a fully managed, cloud-based search service used for building a rich search experience into custom apps. Ez a cikk ismerteti azokat a szolgáltatás-felügyeleti feladatokat, amelyeket elvégezhet a Azure Portalban egy már üzembe helyezett keresési szolgáltatáshoz.This article covers the service administration tasks that you can perform in the Azure portal for a search service that you've already provisioned. A szolgáltatás felügyeletét könnyű megtervezni, a következő feladatokra korlátozódik:Service administration is lightweight by design, limited to the following tasks:

  • A szolgáltatáshoz való olvasási vagy írási hozzáféréshez használt API-kulcsok elérésének kezelése.Manage access to the api-keys used for read or write access to your service.
  • A szolgáltatás kapacitása a partíciók és a replikák kiosztásának módosításával állítható be.Adjust service capacity by changing the allocation of partitions and replicas.
  • Az erőforrás-használat figyelése a szolgáltatási szintek maximális korlátaihoz képest.Monitor resource usage, relative to maximum limits of your service tier.

Figyelje meg, hogy a frissítés nem rendszergazdai feladatként van felsorolva.Notice that upgrade is not listed as an administrative task. Mivel a szolgáltatás kiosztásakor az erőforrások le vannak foglalva, a másik szintjére való áttéréshez új szolgáltatásra van szükség.Because resources are allocated when the service is provisioned, moving to a different tier requires a new service. További információ: Azure Cognitive Search szolgáltatás létrehozása.For details, see Create an Azure Cognitive Search service.

Megfigyelheti a lekérdezési köteteket és egyéb mérőszámokat, és ezekkel az adatokkal módosíthatja a szolgáltatást a gyorsabb válaszidő érdekében.You can monitor query volume and other metrics, and use those insights to adjust your service for faster response times. További információ: a használat és a lekérdezés metrikáinak és teljesítményének és optimalizálásánakfigyelése.For more information, see Monitor usage and query metrics and Performance and optimization.

Rendszergazdai jogosultságokAdministrator rights

A szolgáltatás kiépítés vagy leszerelése egy Azure-előfizetés rendszergazdája vagy egy társ-rendszergazda által végezhető el.Provisioning or decommissioning the service itself can be done by an Azure subscription administrator or co-administrator.

A szolgáltatáson belül bárki, aki hozzáféréssel rendelkezik a szolgáltatás URL-címéhez, és a felügyeleti API-kulcs írási-olvasási hozzáféréssel rendelkezik a szolgáltatáshoz.Within a service, anyone with access to the service URL and an admin api-key has read-write access to the service. Az írási és olvasási hozzáférés lehetővé teszi a kiszolgálói objektumok hozzáadását, törlését és módosítását, beleértve az API-kulcsokat, az indexeket, az indexelő, az adatforrásokat, az ütemterveket és a szerepkör-hozzárendeléseket, amelyeket a RBAC-definiált szerepkörökkelimplementáltakRead-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.

Az Azure Cognitive Search összes felhasználói interakciója a következő módok egyikén esik: írási-olvasási hozzáférés a szolgáltatáshoz (rendszergazdai jogosultságok), vagy csak olvasási hozzáférés a szolgáltatáshoz (lekérdezési jogosultságok).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). További információ: az API-kulcsok kezelése.For more information, see Manage the api-keys.

Naplózási és rendszerinformációkLogging and system information

Az Azure Cognitive Search a portálon vagy a programozott felületen keresztül nem teszi elérhetővé az egyes szolgáltatások naplófájljait.Azure Cognitive Search does not expose log files for an individual service either through the portal or programmatic interfaces. Az alapszintű és újabb verziók esetében a Microsoft minden Azure Cognitive Search-szolgáltatást az 99,9%-os rendelkezésre állást figyeli a szolgáltatói szerződések (SLA) esetében.At the Basic tier and above, Microsoft monitors all Azure Cognitive Search services for 99.9% availability per service level agreements (SLA). Ha a szolgáltatás lassú, vagy az átviteli sebesség az SLA-küszöbérték alá esik, a támogatási csapatoknak tekintse át a rendelkezésre álló naplófájlokat, és foglalkozzon a probléma megoldásával.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.

A szolgáltatással kapcsolatos általános információk tekintetében a következő módokon szerezhet be információkat:In terms of general information about your service, you can obtain information in the following ways:

Erőforrás-használat figyeléseMonitor resource usage

Az irányítópulton az erőforrás-figyelés a szolgáltatás irányítópultján megjelenő információkra korlátozódik, és néhány mérőszámot, amelyet a szolgáltatás lekérdezésével érhet el.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. A szolgáltatás irányítópultjának használat szakaszában gyorsan meghatározhatja, hogy a partíciós erőforrások szintje megfelelő-e az alkalmazáshoz.On the service dashboard, in the Usage section, you can quickly determine whether partition resource levels are adequate for your application. Ha a naplózott eseményeket szeretné rögzíteni és megőrizni, külső erőforrásokat (például az Azure-figyelést) is kiépítheti.You can provision external resources, such as Azure monitoring, if you want to capture and persist logged events. További információ: az Azure Cognitive Search figyelése.For more information, see Monitoring Azure Cognitive Search.

A Search szolgáltatás REST API használatával a dokumentumok és indexek száma programozott módon is elvégezhető:Using the search service REST API, you can get a count on documents and indexes programmatically:

Vész-helyreállítási és szolgáltatás-kimaradásokDisaster recovery and service outages

Bár az adatai megmentését is lehetővé teszi, az Azure Cognitive Search nem biztosítja a szolgáltatás azonnali feladatátvételét, ha a fürt vagy az adatközpont szintjén áramkimaradás történik.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. Ha egy fürt meghibásodik az adatközpontban, az operatív csapat felismeri és a szolgáltatás visszaállítását végzi.If a cluster fails in the data center, the operations team will detect and work to restore service. A szolgáltatás visszaállítása során állásidőt tapasztalhat, de a szolgáltatási kreditek igénylésével kompenzálhatja a szolgáltatás nem rendelkezésre állását a szolgáltatói szerződés (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).

Ha a Microsoft általi ellenőrzésen kívüli katasztrofális hibák esetén folyamatos szolgáltatásra van szükség, egy másik régióban is kiépítheti a további szolgáltatásokat, és a Geo-replikációs stratégia megvalósításával biztosíthatja, hogy az indexek teljes mértékben redundánsak legyenek az összes szolgáltatásban.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.

Azok az ügyfelek, akik Indexelő adatokat használnak az indexek feltöltéséhez és frissítéséhez, az azonos adatforrást használó geo-specifikus indexelő segítségével kezelhetik a vész-helyreállítást.Customers who use indexers to populate and refresh indexes can handle disaster recovery through geo-specific indexers leveraging the same data source. A különböző régiókban található két szolgáltatás, amelyek mindegyike indexelt, indexelheti ugyanazt az adatforrást a Geo-redundancia eléréséhez.Two services in different regions, each running an indexer, could index the same data source to achieve geo-redundancy. Ha olyan adatforrásokból származó indexelést is használ, amelyek földrajzilag redundánsak, vegye figyelembe, hogy az Azure Cognitive Search indexelő csak növekményes indexelést végezhetnek (új, módosított vagy törölt dokumentumokból származó frissítések egyesítése) az elsődleges replikából.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. Feladatátvételi esemény esetén ügyeljen arra, hogy az indexelő újra az új elsődleges replikára irányítsa.In a failover event, be sure to re-point the indexer to the new primary replica.

Ha nem használ indexelő funkciót, az alkalmazás kódjával párhuzamosan küldheti el az objektumokat és az adatait a különböző keresési szolgáltatásoknak.If you do not use indexers, you would use your application code to push objects and data to different search services in parallel. További információ: teljesítmény és optimalizálás az Azure Cognitive Searchban.For more information, see Performance and optimization in Azure Cognitive Search.

Biztonsági mentés és visszaállításBackup and restore

Mivel az Azure Cognitive Search nem elsődleges adattárolási megoldás, nem biztosítunk formális mechanizmust az önkiszolgáló biztonsági mentéshez és visszaállításhoz.Because Azure Cognitive Search is not a primary data storage solution, we do not provide a formal mechanism for self-service backup and restore. Az Azure Cognitive Search .net minta -tárházban található index-Backup-Restore mintakód használatával azonban az index definícióját és a pillanatképet egy sor JSON-fájlra is felhasználhatja, majd ezekkel a fájlokkal visszaállíthatja az indexet, ha szükséges.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. Ez az eszköz az indexeket is át tudja helyezni a szolgáltatási szintek között.This tool can also move indexes between service tiers.

Ellenkező esetben az index létrehozásához és feltöltéséhez használt alkalmazás kódja a de facto Visszaállítási lehetőség, ha tévedésből töröl egy indexet.Otherwise, your application code used for creating and populating an index is the de facto restore option if you delete an index by mistake. Az indexek újraépítéséhez törölnie kell azt (feltéve, hogy létezik), újra létre kell hoznia az indexet a szolgáltatásban, majd újra kell töltenie az adatok elsődleges adattárból való beolvasásával.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.

Felfelé és lefelé skálázásScale up or down

Minden keresési szolgáltatás legalább egy replikával és egy partícióval indul el.Every search service starts with a minimum of one replica and one partition. Ha olyan platformra regisztrált, amely dedikált erőforrásokat biztosít, a szolgáltatás Irányítópultján kattintson a Méretezés csempére az erőforrás-használat módosításához.If you signed up for a tier that provides dedicated resources, click the SCALE tile in the service dashboard to adjust resource usage.

Ha erőforráson keresztül ad hozzá kapacitást, a szolgáltatás automatikusan ezeket használja.When you add capacity through either resource, the service uses them automatically. Az Ön részéről nincs szükség további műveletre, de az új erőforrás hatásának megvalósulása némi késéssel jár.No further action is required on your part, but there is a slight delay before the impact of the new resource is realized. További erőforrások kiépítéséhez akár 15 percet is igénybe vehet.It can take 15 minutes or more to provision additional resources.

Replikák hozzáadásaAdd replicas

A lekérdezések másodpercenkénti száma (QPS) vagy a magas rendelkezésre állás elérése a replikák hozzáadásával történik.Increasing queries per second (QPS) or achieving high availability is done by adding replicas. Minden replika egyetlen másolattal rendelkezik egy indexből, így a szolgáltatás lekérdezési kéréseinek kiszolgálásához még egy replika hozzáadására van lehetőség.Each replica has one copy of an index, so adding one more replica translates to one more index available for handling service query requests. A magas rendelkezésre álláshoz legalább 3 replika szükséges (lásd a kapacitás megtervezését a részletekért).A minimum of 3 replicas are required for high availability (see Capacity Planning for details).

A több replikát tartalmazó keresési szolgáltatás a lekérdezési kérelmeket nagyobb számú indexnél tudja betölteni.A search service having more replicas can load balance query requests over a larger number of indexes. A lekérdezési mennyiség szintje miatt a lekérdezési átviteli sebesség gyorsabb lesz, ha a kérés kiszolgálásához több példány is rendelkezésre áll az indexben.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. Ha a lekérdezés késését tapasztalja, pozitív hatással lehet a teljesítményre, ha a további replikák online állapotban vannak.If you are experiencing query latency, you can expect a positive impact on performance once the additional replicas are online.

Bár a lekérdezési átviteli sebesség a replikák hozzáadásakor leáll, a replikák szolgáltatáshoz való hozzáadásakor nem lehet pontosan dupla vagy tripla.Although query throughput goes up as you add replicas, it does not precisely double or triple as you add replicas to your service. Az összes keresési alkalmazásra olyan külső tényezők vonatkoznak, amelyek hatással lehetnek a lekérdezési teljesítményre.All search applications are subject to external factors that can impinge on query performance. Az összetett lekérdezések és a hálózati késés két tényező, amelyek hozzájárulnak a lekérdezési válaszidő változásaihoz.Complex queries and network latency are two factors that contribute to variations in query response times.

Partíciók hozzáadásaAdd partitions

A legtöbb szolgáltatásalkalmazás több replikát igényel a partíciók helyett.Most service applications have a built-in need for more replicas rather than partitions. Azokban az esetekben, amikor a megnövelt dokumentumok száma kötelező, partíciókat adhat hozzá, ha regisztrált a standard szolgáltatásra.For those cases where an increased document count is required, you can add partitions if you signed up for Standard service. Az alapszintű csomag nem biztosít további partíciókat.Basic tier does not provide for additional partitions.

A standard szinten a partíciók a 12 (pontosabb, 1, 2, 3, 4, 6 vagy 12) többszörösében lesznek hozzáadva.At the Standard tier, partitions are added in multiples of 12 (specifically, 1, 2, 3, 4, 6, or 12). Ez egy horizontális skálázási összetevő.This is an artifact of sharding. Az indexek 12 szegmensben jönnek létre, amelyek mindegyike 1 partíción tárolható, vagy egyenlően 2, 3, 4, 6 vagy 12 partícióra osztható (egy-egy szegmens/partíció).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).

Replikák eltávolításaRemove replicas

A nagy mennyiségű lekérdezési kötetek után a csúszka segítségével csökkentheti a replikákat a keresési lekérdezés terhelésének normalizálása után (például az üdülési értékesítések felett).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). Az Ön részéről nincs szükség további lépésekre.There are no further steps required on your part. A replikák számának csökkentése lemond az adatközpontban található virtuális gépekről.Lowering the replica count relinquishes virtual machines in the data center. A lekérdezési és az adatfeldolgozási műveletek mostantól kevesebb virtuális gépen futnak, mint korábban.Your query and data ingestion operations will now run on fewer VMs than before. A minimális követelmény egy replika.The minimum requirement is one replica.

Partíciók eltávolításaRemove partitions

A replikák eltávolításával szemben, amelyhez nincs szükség további erőfeszítésre, előfordulhat, hogy néhány teendője van, ha több tárterületet használ, mint amennyit csökkenteni lehet.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. Ha például a megoldás három partíciót használ, az egy vagy két partícióra való leépítés hibát eredményez, ha az új tárolóhely kisebb, mint az index üzemeltetéséhez szükséges.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. Az elvárásoknak megfelelően lehetőség van az indexek vagy dokumentumok törlésére egy társított indexen belül, hogy felszabadítsa a helyet, vagy megtartja a jelenlegi konfigurációt.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.

Nincs olyan észlelési módszer, amely közli, hogy mely indexek vannak tárolva egy adott partíción.There is no detection method that tells you which index shards are stored on specific partitions. Az egyes partíciók körülbelül 25 GB tárhelyet biztosítanak, ezért a tárterületet a szükséges partíciók számával kell csökkenteni.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. Ha egy partícióra kíván visszaállítani, akkor mind a 12 szegmensnek el kell férnie.If you want to revert to one partition, all 12 shards will need to fit.

Ha segítségre van szüksége a jövőbeli tervezéssel kapcsolatban, érdemes lehet megtekinteni a tárterületet (az indexek statisztikájának lekérésehasználatával), hogy megtekintse, mennyit használtTo help with future planning, you might want to check storage (using Get Index Statistics) to see how much you actually used.

Következő lépésekNext steps

Ha megértette a Service Administration mögötti fogalmakat, érdemes lehet a PowerShell használatával automatizálni a feladatokat.Once you understand the concepts behind service administration, consider using PowerShell to automate tasks.

Javasoljuk továbbá a teljesítmény-és optimalizálási cikkáttekintését.We also recommend reviewing the performance and optimization article.