Snowpark Container Services : utilisation des pools de calcul¶
Un pool de calcul est une collection d’un ou plusieurs nœuds de machines virtuelles (VM) sur lesquels Snowflake exécute vos services Snowpark Container Services (y compris les services de tâche). Vous créez un pool de calcul à l’aide de la commande CREATE COMPUTE POOL. Vous le spécifiez ensuite lors de la création d’un service ou de l’exécution d’un service de tâche.
Création d’un pool de calcul¶
Un pool de calcul est une construction au niveau du compte, analogue à un entrepôt virtuel Snowflake. L’espace de nommage du pool de calcul est votre compte. En d’autres termes, vous ne pouvez pas avoir plusieurs pools de calcul portant le même nom dans votre compte.
Les informations minimales requises pour créer un pool de calcul sont les suivantes :
Le type de machine (appelé famille d’instances) à provisionner pour les nœuds du pool de calcul
Le nombre minimum de nœuds pour démarrer un pool de calcul.
Le nombre maximum de nœuds que le pool de calcul peut atteindre (Snowflake gère la mise à l’échelle).
Si vous vous attendez à une charge importante ou à des pics d’activité soudains sur les services que vous avez l’intention d’exécuter dans votre pool de calcul, vous pouvez définir un nombre minimum de nœuds supérieur à 1. Cette approche garantit que des nœuds supplémentaires sont immédiatement disponibles en cas de besoin, au lieu d’attendre le démarrage de la mise à l’échelle automatique.
La définition d’une limite maximale de nœuds permet d’éviter qu’un grand nombre de nœuds ne soient ajoutés à votre pool de calcul par la mise à l’échelle automatique de Snowflake. Cela peut s’avérer crucial dans des scénarios tels que des pics de charge inattendus ou des problèmes dans votre code qui pourraient amener Snowflake à allouer un plus grand nombre de nœuds de pool de calcul que prévu à l’origine.
Pour créer un pool de calcul avec l”Snowsight ou SQL :
- Snowsight:
Dans le menu de navigation, sélectionnez Compute » Compute Pools.
Sélectionnez votre nom d’utilisateur en bas de la barre de navigation et endossez le rôle ACCOUNTADMIN ou à tout autre rôle autorisé à créer un pool de calcul.
Sélectionnez + Compute Pool.
Dans l’UI New compute pool, indiquez les informations requises (le nom du pool de calcul, la famille d’instances et la limite de nœuds).
Sélectionnez Create Compute Pool.
- SQL:
Exécutez la commande CREATE COMPUTE POOL.
Par exemple, la commande suivante crée un pool de calcul à un nœud :
CREATE COMPUTE POOL tutorial_compute_pool MIN_NODES = 1 MAX_NODES = 1 INSTANCE_FAMILY = CPU_X64_XS;
La famille d’instances identifie le type de machine que vous souhaitez provisionner pour les nœuds de calcul dans le pool de calcul. La spécification de la famille d’instances lors de la création d’un pool de calcul est similaire à la spécification de la taille de l’entrepôt (XSMALL, SMALL, MEDIUM, LARGE et ainsi de suite) lors de la création d’un entrepôt. Le tableau suivant répertorie les types de machines disponibles. Vous pouvez également utiliser la commande SHOW COMPUTE POOL INSTANCE FAMILIES pour obtenir cette liste de familles d’instances disponibles.
Available instance families (machine types) for compute pool nodes¶
INSTANCE_FAMILY, voir Tableau de consommation du service Snowflake
vCPU
Mémoire (GiB)
Stockage (GB)
Limite de bande passante (Gb/s)
GPU
Mémoire GPU par GPU (GiB)
Limite du nœud
Description
CPU_X64_XS
1
6
100
Jusqu’à 12,5
s/o
s/o
150
La plus petite instance disponible pour les conteneurs Snowpark. Idéal pour réaliser des économies et démarrer.
CPU_X64_S
3
13
100
Jusqu’à 12,5
s/o
s/o
150
Idéal pour héberger plusieurs services/tâches tout en réduisant les coûts.
CPU_X64_M
6
28
100
Jusqu’à 12,5
s/o
s/o
150
Idéal pour les applications full stack ou les services multiples
CPU_X64_SL (except China)
14
54
100
Jusqu’à 12,5
s/o
s/o
150
Pour les applications qui nécessitent un nombre élevé de CPUs, de mémoire et de stockage.
CPU_X64_L
28
116
100
12,5
s/o
s/o
150
Pour les applications qui nécessitent un nombre anormalement élevé de CPUs, de mémoire et de stockage.
HIGHMEM_X64_S
6
58
100
AWS et GCP : jusqu’à 12,5, Azure : 8
s/o
s/o
150
Pour les applications qui utilisent beaucoup de mémoire.
HIGHMEM_X64_M
28
AWS : 240, Azure et GCP : 244
100
AWS : 12,5, Azure et GCP : 16
s/o
s/o
150
Pour héberger plusieurs applications qui utilisent beaucoup en mémoire sur une seule machine.
HIGHMEM_X64_SL (Azure and GCP, except GCP Dammam region)
92
654
100
32
s/o
s/o
20
La machine Azure ou GCP qui dispose de la plus grande mémoire disponible pour traiter de grandes quantités de données en mémoire.
HIGHMEM_X64_L (AWS only)
124
984
100
50
s/o
s/o
150
La machine AWS qui dispose de la plus grande mémoire disponible pour traiter de grandes quantités de données en mémoire.
GPU_NV_S (AWS only, except Singapore, Switzerland North, Paris, and Osaka regions)
6
27
300 (NVMe)
Jusqu’à 10
1 NVIDIA A10G
24
150
Notre plus petite taille de GPU NVIDIA disponible pour les conteneurs Snowpark pour commencer.
GPU_NV_M (AWS only, except gov regions, Singapore, Switzerland North, Paris, and Osaka regions)
44
178
3,4 TB (NVMe)
40
4 NVIDIA A10G
24
10
Optimisé pour les scénarios d’utilisation intensive de GPU comme la vision par ordinateur ou LLMs/VLMs
GPU_NV_L (AWS only, available only in AWS US West and US East non-gov regions by request; limited availability might be possible in other regions upon request)
92
1112
6,8 TB (NVMe)
400
8 NVIDIA A100
40
À la demande
La plus grande instance de GPU pour les cas de GPU spécialisés et avancés tels que LLMs et clustering, etc.
GPU_NV_XS (Azure uniquement, à l’exception des régions Suisse Nord, UAE Nord, US Centre et UK Sud)
3
26
100
8
1 NVIDIA T4
16
10
Notre plus petite taille de GPU NVIDIA Azure disponible pour les conteneurs Snowpark pour commencer.
GPU_NV_SM (Azure uniquement, à l’exception de la région US Centre)
32
424
100
40
1 NVIDIA A10
24
10
Une taille plus petite de GPU NVIDIA Azure disponible pour les conteneurs Snowpark pour commencer.
GPU_NV_2M (Azure uniquement, à l’exception de la région US Centre)
68
858
100
80
2 NVIDIA A10
24
5
Optimisé pour les scénarios d’utilisation intensive de GPU comme la vision par ordinateur ou LLMs/VLMs
GPU_NV_3M (Azure uniquement, à l’exception des régions US Centre, Europe Nord et UAE Nord)
44
424
100
40
2 NVIDIA A100
80
À la demande
Optimisé pour les scénarios d’utilisation intensive de GPU comme la vision par ordinateur ou LLMs/VLMs
GPU_NV_SL (Azure uniquement, à l’exception des régions US Centre, Europe Nord et UAE Nord)
92
858
100
80
4 NVIDIA A100
80
À la demande
La plus grande instance de GPU pour les cas de GPU spécialisés et avancés tels que LLMs et clustering, etc.
GPU_GCP_NV_L4_1_24G (Google Cloud uniquement)
6
28
300
Jusqu’à 16
1 NVIDIA L4
24
10
Notre plus petite taille de GPU NVIDIA disponible pour les conteneurs Snowpark pour commencer.
GPU_GCP_NV_L4_4_24G (Google Cloud uniquement)
44
178
1200
Jusqu’à 50
4 NVIDIA L4
24
10
Scénarios d’utilisation de GPU comme la vision par ordinateur ou les LLMs.
GPU_GCP_NV_A100_8_40G (Google Cloud uniquement, disponible uniquement dans les régions GCP US Centre1 et Europe Ouest4 sur demande)
92
654
2500
Jusqu’à 100
8 NVIDIA A100
40
À la demande
Optimisé pour les scénarios d’utilisation intensive de GPU comme la vision par ordinateur ou LLMs/VLMs
Pour plus d’informations sur les familles d’instances disponibles, voir CREATE COMPUTE POOL.
Mise à l’échelle automatique des nœuds d’un pool de calcul¶
Après avoir créé un pool de calcul, Snowflake lance le nombre minimum de nœuds et crée automatiquement des nœuds supplémentaires jusqu’au maximum autorisé. C’est ce qu’on appelle la mise à l’échelle automatique. De nouveaux nœuds sont attribués lorsque les nœuds en service ne peuvent plus supporter de charge de travail supplémentaire. Par exemple, supposons que deux instances de service s’exécutent sur deux nœuds de votre pool de calcul. Si vous exécutez un autre service dans le même pool de calcul, les besoins en ressources supplémentaires peuvent amener Snowflake à démarrer un nœud supplémentaire.
Toutefois, si aucun service n’est exécuté sur un nœud pendant une durée déterminée, Snowflake supprime automatiquement le nœud, garantissant ainsi que le pool de calcul conserve le nombre minimum de nœuds requis, même après la suppression.
Gestion d’un pool de calcul¶
Vous pouvez gérer un pool de calcul avec l”Snowsight ou SQL.
Dans l”Snowsight, vous choisissez l’option Plus (…) à côté du nom du pool de calcul, et vous choisissez l’opération souhaitée dans le menu. Cette section explique les commandes SQL que vous pouvez utiliser pour gérer un pool de calcul.
Snowpark Container Services fournit les commandes suivantes pour gérer les pools de calcul :
Surveillance : utilisez la commande SHOW COMPUTE POOLS pour obtenir des informations sur les pools de calcul.
Fonctionnement : utilisez la commande ALTER COMPUTE POOL pour modifier l’état d’un pool de calcul.
ALTER COMPUTE POOL <name> { SUSPEND | RESUME | STOP ALL }
Lorsque vous suspendez un pool de calcul, Snowflake suspend tous les services à l’exception des services de tâches. Les services de tâches continuent de fonctionner jusqu’à ce qu’ils atteignent un état terminal (DONE ou FAILED), après quoi les nœuds de calcul sont libérés.
Un pool de calcul suspendu doit être repris avant que vous ne puissiez démarrer un nouveau service. Si le pool de calcul est configuré pour une reprise automatique (avec la propriété AUTO_RESUME définie sur TRUE), Snowflake reprend automatiquement le pool lorsqu’un service lui est soumis. Sinon, vous devez exécuter la commande ALTER COMPUTE POOL pour reprendre manuellement le pool de calcul.
Modification : utilisation de la commande ALTER COMPUTE POOL pour modifier les propriétés du pool de calcul.
ALTER COMPUTE POOL <name> SET propertiesToAlter = <value> propertiesToAlter := { MIN_NODES | MAX_NODES | AUTO_RESUME | AUTO_SUSPEND_SECS | COMMENT }
Lorsque vous diminuez MAX_NODES, tenez compte des effets potentiels suivants :
Snowflake peut avoir besoin de mettre fin à une ou plusieurs instances de service et de les redémarrer sur d’autres nœuds disponibles dans le pool de calcul. Si MAX_NODES est défini sur une valeur trop faible, Snowflake peut être incapable de planifier certaines instances de service.
Si le nœud interrompu avait un service de tâche en cours d’exécution, l’exécution de la tâche échouera. Snowflake ne redémarrera pas le service de tâche.
Exemple :
ALTER COMPUTE POOL my_pool SET MIN_NODES = 2 MAX_NODES = 2;
Suppression : utilisez la commande DROP COMPUTE POOL pour supprimer un pool de calcul.
Exemple :
DROP COMPUTE POOL <name>
Vous devez arrêter tous les services en cours d’exécution avant de pouvoir supprimer un pool de calcul.
Répertorier les pools de calcul et afficher les propriétés : utilisez les commandes SHOW COMPUTE POOLS et DESCRIBE COMPUTE POOL. Pour des exemples, voir Afficher les pools de calcul.
Cycle de vie d’un pool de calcul¶
Un pool de calcul peut se trouver dans l’un des états suivants :
IDLE : le pool de calcul dispose du nombre souhaité de nœuds de machines virtuelles (VM), mais aucun service n’est planifié. Dans cet état, la mise à l’échelle automatique peut réduire le pool de calcul à la taille minimale en raison d’un manque d’activité.
ACTIVE : le pool de calcul a au moins un service en cours d’exécution ou planifié. Le pool peut augmenter (jusqu’au nombre maximal de nœuds) ou diminuer (jusqu’au nombre minimal de nœuds) en fonction de la charge ou des actions de l’utilisateur.
SUSPENDED : le pool ne contient actuellement aucun nœud de machine virtuelle en cours d’exécution, mais si la propriété du pool de calcul AUTO_RESUME est définie sur TRUE, le pool reprendra automatiquement lorsqu’un service sera planifié.
Les états suivants sont transitoires :
STARTING : lorsque vous créez ou reprenez un pool de calcul, celui-ci entre dans l’état STARTING jusqu’à ce qu’au moins un nœud soit provisionné.
STOPPING : lorsque vous suspendez un pool de calcul (en utilisant ALTER COMPUTE POOL), le pool de calcul entre dans l’état STOPPING jusqu’à ce que Snowflake ait libéré tous les nœuds du pool de calcul. Lorsque vous suspendez un pool de calcul, Snowflake suspend tous les services à l’exception des services de tâches. Les services de tâches continuent de fonctionner jusqu’à ce qu’ils atteignent un état terminal (DONE ou FAILED), après quoi les nœuds de calcul sont libérés.
RESIZING : lorsque vous créez un pool de calcul, il entre initialement dans l’état STARTING. Après avoir provisionné un nœud, il entre dans l’état RESIZING jusqu’à ce que le nombre minimum de nœuds (tel que spécifié dans CREATE COMPUTE POOL) soit provisionné. Lorsque vous modifiez un pool de calcul (ALTER COMPUTE POOL) et que vous mettez à jour les valeurs minimales et maximales des nœuds, le pool entre dans l’état RESIZING jusqu’à ce que le nombre minimal de nœuds soit provisionné. Notez que la mise à l’échelle automatique d’un pool de calcul place également le pool de calcul dans l’état RESIZING.
Pour plus d’informations sur la manière dont les coûts ont été encourus pendant les différents états du cycle de vie du pool de calcul, voir Calculer le coût du pool de calcul.
Privilèges de pool de calcul¶
Lorsque vous travaillez avec des pools de calcul, le modèle de privilège suivant s’applique :
Pour créer un pool de calcul dans un compte, le rôle actuel doit disposer du privilège CREATE COMPUTE POOL sur le compte. Si vous créez un pool, vous disposez, en tant que propriétaire, de l’autorisation OWNERSHIP, qui vous permet d’exercer un contrôle total sur ce pool de calcul. Le fait d’avoir l’autorisation OWNERSHIP sur un pool de calcul n’implique aucune permission sur les autres pools de calcul.
Pour la gestion du pool de calcul, les privilèges (capacités) suivants sont pris en charge :
Privilège
Utilisation
MODIFY
Permet de modifier toutes les propriétés du pool de calcul, y compris la taille.
MONITOR
Permet de visualiser l’utilisation du pool de calcul, y compris la description des propriétés du pool de calcul.
OPERATE
Permet de modifier l’état du pool de calcul (suspension, reprise). En outre, il permet d’arrêter tous les services planifiés (y compris les services de tâches).
USAGE
Permet de créer des services dans le pool de calcul. Notez que lorsqu’un pool de calcul est suspendu et que sa propriété AUTO_RESUME est définie sur true, un rôle disposant de l’autorisation USAGE sur le pool de calcul peut implicitement déclencher la reprise du pool de calcul lorsqu’il démarre ou reprend un service, même si le rôle ne dispose pas de l’autorisation OPERATE.
OWNERSHIP
Donne un contrôle total sur le pool de calcul. Un seul rôle peut détenir ce privilège sur un objet spécifique à la fois.
ALL [ PRIVILEGES ]
Accorde tous les privilèges, sauf OWNERSHIP, sur le pool de calcul.
Maintenance du pool de calcul¶
Dans le cadre de la maintenance courante de l’infrastructure interne, Snowflake met régulièrement à jour les nœuds de calcul afin de garantir des performances et une sécurité optimales. Cela inclut les mises à niveau du système d’exploitation, les améliorations des pilotes et les correctifs de sécurité. La maintenance consiste à remplacer les nœuds obsolètes par des nœuds mis à jour toutes les quelques semaines, chaque nœud étant actif jusqu’à un mois.
Fenêtre de maintenance¶
En général, la maintenance planifiée a lieu tous les samedis à partir de 8 PM jusqu’au dimanche à 8 AM, et chaque dimanche à partir de 8 PM jusqu’au lundi à 8 AM. Pour les comptes d’accès anticipé, la maintenance a lieu quotidiennement à partir de 11 PM et peut prendre jusqu’à 6 heures.
Interruption de service¶
Pendant la maintenance, Snowflake recrée automatiquement sur les nouveaux nœuds de calcul les instances de service fonctionnant sur les anciens nœuds de calcul. Snowflake utilise une méthode de roulement pour recréer les instances de service.
Si un service n’a qu’une seule instance, le service est interrompu pendant que Snowflake recrée l’instance.
Pour les services comportant plusieurs instances, Snowflake recrée les instances du service de manière incrémentale sur les nœuds mis à niveau. Pas plus de 50 % des instances de service sont remplacées à la fois. Notez qu’il se peut que le nombre d’instances disponibles soit inférieur aux MIN_INSTANCES requises pour le service. Si le nombre d’instances disponibles est inférieur à MIN_READY_INSTANCES, le service passe de l’état READY à l’état PENDING, ce qui entraîne une interruption du service. Par conséquent, pour éviter toute interruption de service, envisagez de définir MIN_READY_INSTANCES à moins de 50 % de MIN_INSTANCES.
Les services en cours seront interrompus et devront être relancés par les clients une fois la maintenance terminée.
Attention
Les interruptions de service pendant une fenêtre de maintenance ou des mises à jour critiques ne sont pas couvertes par le niveau de service défini dans Politique de support et accord de niveau de service de Snowflake.
Bonnes pratiques pour limiter les temps d’arrêt¶
Exécuter plusieurs instances de service : L’existence de plusieurs instances minimise les interruptions de service lors des opérations de maintenance, ce qui garantit une grande disponibilité.
Stocker l’état de l’application dans un stockage persistant : Stockez les données et les objets avec état sur un stockage persistant, y compris un stockage en bloc, des zones de préparation Snowflake ou des tables Snowflake.
Attraper le signal SIGTERM : Lors de la fermeture d’une instance de service, Snowflake envoie d’abord un signal SIGTERM à chaque conteneur de service (voir Mettre fin au service). Dans le cadre du traitement du signal, le code du conteneur peut sauvegarder l’état du service avant que l’instance du service ne soit arrêtée ou redémarrée.
Concevoir des services à haute disponibilité pour qu’ils fonctionnent dans un état dégradé pendant la maintenance : Pour rester disponible pendant la maintenance, votre service doit pouvoir tolérer de ne fonctionner qu’avec 50 % des instances.
Fournir un indicateur de disponibilité : Si vous ne fournissez pas de sonde de préparation, Snowflake suppose que votre instance de service est prête dès que le code commence à s’exécuter. En général, il faut un certain temps pour qu’un conteneur termine son initialisation et soit prêt à traiter les requêtes. Vous devez fournir une sonde de préparation dans la configuration du service pour indiquer explicitement à Snowflake que votre instance de service est prête à traiter les requêtes.
Surveiller les planifications de maintenance : Évitez de planifier des tâches critiques pendant une fenêtre de maintenance.
Éviter de planifier l’exécution du service pendant les fenêtres de maintenance : Snowflake risque d’annuler un job en cours d’exécution pendant une fenêtre de maintenance.
Effectuer des sauvegardes ou des points de contrôle réguliers : Effectuez périodiquement des sauvegardes ou des points de contrôle de l’état de votre application sur le stockage persistant (y compris le stockage en bloc, les zones de préparation Snowflake ou les tables Snowflake).
Comment les services sont planifiés sur un pool de calcul¶
Au moment de créer un service, vous pouvez choisir d’exécuter plusieurs instances pour gérer la charge entrante. Snowflake utilise les directives générales suivantes pour planifier vos instances de service sur les nœuds du pool de calcul :
Tous les conteneurs d’une instance de service s’exécutent toujours sur un seul nœud de pool de calcul. En d’autres termes, une instance de service ne s’étend jamais sur plusieurs nœuds.
Lorsque vous exécutez plusieurs instances de service, Snowflake peut les exécuter sur le même nœud ou sur différents nœuds au sein du pool de calcul. Lorsque cette décision est prise, Snowflake prend en compte toutes les exigences spécifiées en matière de ressources matérielles (telles que la mémoire et le GPU) comme indiqué dans le fichier de spécification du service (voir champ containers.resources).
Par exemple, supposons que chaque nœud de votre pool de calcul dispose de 8 GB de mémoire. Si la spécification de votre service inclut une exigence de mémoire 6 GB, et que vous choisissez d’exécuter deux instances lors de la création d’un service, Snowflake ne peut pas exécuter les deux instances sur le même nœud. Dans ce cas, Snowflake planifie chaque instance sur un nœud distinct au sein du pool de calcul afin de répondre aux exigences en matière de mémoire.
Note
Snowflake prend en charge les montages de zones de préparation à utiliser par les conteneurs d’application. La zone de préparation interne de Snowflake est l’un des types de volumes de stockage pris en charge.
Pour des performances optimales, Snowflake limite désormais le nombre total de montages de volume de la zone de préparation jusqu’à huit par nœud de pool de calcul, que ces volumes appartiennent ou non à la même instance de service, au même service ou à des services différents.
Lorsque la limite d’un nœud est atteinte, Snowflake n’utilise pas ce nœud pour démarrer de nouvelles instances de service qui utilisent un volume de zone de préparation. Si la limite est atteinte sur tous les nœuds du pool de calcul, Snowflake ne pourra pas démarrer votre instance de service. Dans ce scénario, lorsque vous exécutez la commande SHOW SERVICE CONTAINERS IN SERVICE, Snowflake revient au statut PENDING avec le message « Non planifiable en raison de ressources insuffisantes ».
Pour prendre en charge cette limite d’allocation de montage de zone de préparation sur un nœud, dans certains cas, vous pouvez augmenter le nombre maximal de nœuds que vous demandez pour un pool de calcul. Cela garantit que des nœuds supplémentaires sont disponibles pour que Snowflake puisse démarrer vos instances de service.
System compute pools¶
Snowflake automatically provisions two compute pools in each Snowflake account. These compute pools are provided exclusively for the following Snowflake workloads.
Notebooks
Model serving
ML jobs
By using system compute pools, users can run these workload without needing an account administrator to configure a compute pool first.
The system compute pools have the following default configuration:
Compute pool name: SYSTEM_COMPUTE_POOL_GPU
Famille d’instances : Selon que votre compte Snowflake se trouve dans AWS ou dans des régions Microsoft Azure, Snowflake utilise la famille d’instances GPU suivante pour ce pool de calcul.
Dans Azure, GPU_NV_SM.
Dans AWS, GPU_NV_S.
Notez que les régions suivantes ne prennent pas en charge SYSTEM_COMPUTE_POOL_GPU :
Dans AWS : Singapour, Suisse Nord, Paris et Osaka.
Dans Azure : Centre des US.
Google Cloud : Le pool de calcul GPU n’est pas disponible.
Configuration par défaut :
MIN_NODES=1
MAX_NODES=50
INITIALLY_SUSPENDED=true
AUTO_SUSPEND_SECS=600
Compute pool name: SYSTEM_COMPUTE_POOL_CPU
Famille d’instances : CPU_X64_S
Configuration par défaut :
MIN_NODES=1
MAX_NODES=150
INITIALLY_SUSPENDED=true
AUTO_SUSPEND_SECS=600
Note that,
Compute pools are initially in a suspended state and only begin incurring costs when a supported Snowflake workload starts using them.
If no workloads are running, these compute pools are automatically suspended after 10 minutes. To modify the auto-suspension policy for default compute pools, use the ALTER COMPUTE POOL SET AUTO_SUSPEND_SECS command.
Managing the system compute pools¶
In a Snowflake account, the ACCOUNTADMIN role owns these system compute pools. Administrators have full control over the compute pools, including modifying their properties, suspending operations, and monitoring consumption. The ACCOUNTADMIN role can delete the compute pool. For example:
USE ROLE ACCOUNTADMIN;
ALTER COMPUTE POOL SYSTEM_COMPUTE_POOL_CPU STOP ALL;
DROP COMPUTE POOL SYSTEM_COMPUTE_POOL_CPU;
By default, the USAGE permission on system compute pools is granted to the PUBLIC role, allowing all roles in the account to use them. However, the ACCOUNTADMIN can modify these privileges to restrict access if necessary.
To restrict access to system compute pools to specific roles in your account, use the ACCOUNTADMIN role to revoke the USAGE permission from the PUBLIC role and grant it to the desired role(s). For example:
USE ROLE ACCOUNTADMIN; REVOKE USAGE ON COMPUTE POOL SYSTEM_COMPUTE_POOL_CPU FROM ROLE PUBLIC; GRANT USAGE ON COMPUTE POOL SYSTEM_COMPUTE_POOL_CPU TO ROLE <role-name>;
System compute pools can be associated with budgets. for cost management.
Configuration de vos propres pools de calcul pour les notebooks¶
By default, Notebook services run in system compute pools. If you don’t want to use the Snowflake-provisioned compute pools, you have the option to choose other compute pools in your account for Notebooks. To override the Snowflake-provisioned compute pools you can set these parameters (DEFAULT_NOTEBOOK_COMPUTE_POOL_CPU and DEFAULT_NOTEBOOK_COMPUTE_POOL_GPU). Note that, this will change your Snowsight experience. When creating a Notebook in Snowsight, the compute pool you configure using these parameters appears as the first preference in the UI. The following example commands set these parameters:
Configurez
my_poolcomme votre pool de calcul préféré au niveau du compte pour les notebooks utilisant l’environnement d’exécution GPU.ALTER ACCOUNT SET DEFAULT_NOTEBOOK_COMPUTE_POOL_GPU='my_pool';
Configurez
my_poolcomme votre pool de calcul préféré pour les notebooks créés dans la base de donnéesmy_db.ALTER DATABASE my_db SET DEFAULT_NOTEBOOK_COMPUTE_POOL_GPU='my_pool';
Configurez
my_poolcomme votre pool de calcul préféré pour les notebooks créés dans le schémamy_db.my_schema.ALTER SCHEMA my_db.my_schema SET DEFAULT_NOTEBOOK_COMPUTE_POOL_GPU='my_pool';
Utilisez les commandes suivantes pour vérifier la préférence actuelle du pool de calcul GPU configuré dans votre compte pour exécuter les notebooks :
SHOW PARAMETERS LIKE 'DEFAULT_NOTEBOOK_COMPUTE_POOL_GPU' IN ACCOUNT;
SHOW PARAMETERS LIKE 'DEFAULT_NOTEBOOK_COMPUTE_POOL_GPU' IN DATABASE my_db;
SHOW PARAMETERS LIKE 'DEFAULT_NOTEBOOK_COMPUTE_POOL_GPU' IN SCHEMA my_db.my_schema;
Pour plus d’informations, voir SHOW PARAMETERS.
Lignes directrices et limitations¶
Autorisation CREATE COMPUTE POOL : si vous ne pouvez pas créer un pool de calcul sous le rôle actuel, consultez votre administrateur de compte pour accorder la permission. Par exemple :
GRANT CREATE COMPUTE POOL ON ACCOUNT TO ROLE <role_name> [WITH GRANT OPTION];
Pour plus d’informations, consultez GRANT <privilèges> … TO ROLE.
Limite par compte sur les nœuds du pool de calcul.
Le nombre de nœuds que vous pouvez créer dans votre compte (quel que soit le nombre de pools de calcul) est limité à 500.
Le nombre maximal de nœuds par pool de calcul est 50.
De plus, il existe une limite au nombre de nœuds autorisés pour chaque famille d’instances (voir la colonne Limite de nœuds dans le tableau des familles d’instances). Si vous obtenez un message d’erreur du type
Requested number of nodes <#> exceeds the node limit for the account, vous avez rencontré ces limites. Pour plus d’informations, contactez votre représentant de compte.