Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
En esta página, se describe cómo configurar las redes para Google Cloud NetApp Volumes.
NetApp Volumes usa el acceso privado a servicios para crear una conexión privada con una ruta de datos de alto rendimiento y baja latencia.
Consideraciones
Antes de comenzar a configurar la red, ten en cuenta lo siguiente:
No puedes compartir volúmenes entre instancias de nube privada virtual (VPC): Para compartir volúmenes, debes compartir una VPC compartida desde un proyecto host con varios proyectos de servicio. Se puede acceder a los grupos de almacenamiento creados en la VPC compartida desde el proyecto de servicio en todos los proyectos de servicio.
Las conexiones privadas de VPC solo deben configurarse una vez: La conexión privada debe configurarse una vez por VPC. No es necesario que repitas la configuración de la conexión privada para varios proyectos de servicio o regiones.
Debes asignar un rango de CIDR: Los rangos de enrutamiento entre dominios sin clases (CIDR) te permiten representar direcciones IP y sus redes correspondientes para que el servicio las use. El servicio usa direcciones IP del rango de CIDR asignado para asignar volúmenes al tipo de protocolo correcto (Sistema de archivos de red [NFS] o Bloque de mensajes del servidor [SMB]).
Debes configurar el peering de acceso a servicios privados antes de crear tu primer grupo de almacenamiento: Si el peering aún no está configurado, el proceso de creación del grupo de almacenamiento en la consola deGoogle Cloud lo detecta y te solicita que configures el peering con un flujo de trabajo basado en la consola deGoogle Cloud . Si ya existe una conexión de intercambio de tráfico con la VPC especificada, el flujo de trabajo de la consola de Google Cloud la usa. Tanto para el intercambio de tráfico manual como para el basado en la consola de Google Cloud , tienes la opción de especificar manualmente un CIDR o hacer que las redes de Google elijan uno automáticamente.
Elige un rango de CIDR que no entre en conflicto con los rangos de CIDR de la red local: Si planeas usar NetApp Volumes desde redes locales a través de una VPN o Cloud Interconnect, te recomendamos que elijas un rango de CIDR que no entre en conflicto con los rangos de CIDR que se usan en tu red local. Si no lo haces, se pueden producir colisiones de IP y problemas de enrutamiento.
Elige un rango de CIDR: NetApp Volumes usa rangos de direcciones IP públicas de uso privado (PUPI) o RFC 1918, con la excepción de 6.0.0.0/8 y 7.0.0.0/8. PUPI admite volúmenes NFS o SMB, y clientes NFS o SMB que acceden a los volúmenes. Cuando uses direcciones PUPI, usa los comandos de Google Cloud CLI en lugar de la consola de Google Cloud para configurar la red.
Puedes hacer que el acceso privado a servicios seleccione automáticamente un rango de CIDR sin usar o especificarlo de forma manual. La selección manual te permite elegir un rango de direcciones específico.
Elige un rango de CIDR que sea lo suficientemente grande como para admitir tus volúmenes y grupos.
El rango de CIDR mínimo que puedes usar es /24. NetApp Volumes consume rangos secundarios del CIDR asignado según el siguiente conjunto de reglas:
Los grupos de almacenamiento requieren un mínimo de /28 subrangos.
Los volúmenes con niveles de servicio Estándar, Premium y Extremo pueden compartir una sola dirección IP, incluso si se encuentran en diferentes grupos de almacenamiento. Por lo tanto, una gran cantidad de volúmenes y grupos pueden compartir un solo rango secundario de /28.
Según los parámetros del grupo de almacenamiento, como CMEK, LDAP, política de Active Directory y otros, los volúmenes consumirán más IPs.
Cada grupo de almacenamiento de nivel de servicio Flex requiere su propia dirección IP, y todos sus volúmenes usan la misma dirección IP. Por lo tanto, puedes tener 12 agrupaciones de almacenamiento en un subrango de /28, ya que cada subred tiene cuatro direcciones IP inutilizables.
Los volúmenes de gran capacidad (en versión preliminar) en el nivel de servicio Extreme requieren un subrango de /27 para admitir varios extremos de almacenamiento.
Los volúmenes en diferentes regiones del mismo proyecto requieren rangos de /28 o /27 adicionales según el tipo de volúmenes que implementes.
Los volúmenes en diferentes proyectos de servicio en la misma VPC compartida requieren rangos de /28 o /27 individuales. Por lo tanto, el rango de CIDR de /24 de tamaño mínimo puede admitir un máximo de 16 combinaciones de proyectos de servicio y región.
Si un rango secundario existente se queda sin IPs, se pueden consumir rangos secundarios adicionales, incluso para combinaciones idénticas de proyecto, VPC o región.
Habilita la API de Service Networking: Asegúrate de habilitar la API de servicenetworking.googleapis.com.
Reemplaza PROJECT_ID por el nombre del proyecto en el que deseas configurar el acceso privado a servicios.
Puedes especificar varios rangos de direcciones de procesamiento como una lista separada por comas para la marca --ranges. NetApp Volumes usa subrangos /28 o /27 de los rangos de direcciones de procesamiento en un orden indefinido.
Reemplaza ADDITIONAL_IP_RANGES por una lista separada por comas de rangos de direcciones adicionales para el intercambio de tráfico, o bien déjalo vacío para intercambiar tráfico entre las redes solo con el rango de direcciones creado en el paso anterior.
Habilita la propagación de rutas personalizadas. Ten en cuenta que NetApp Volumes crea un intercambio de tráfico de sn-netapp-prod cuando se configura la conexión privada.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-04 (UTC)"],[],[],null,["# Configure networking\n\nThis page describes how to configure networking for Google Cloud NetApp Volumes.\nNetApp Volumes uses [private services access](/vpc/docs/private-services-access)\nto create a high throughput and low-latency data path private connection.\n\nConsiderations\n--------------\n\nConsider the following before you begin to configure networking:\n\n- **You can't share volumes between Virtual Private Cloud (VPC) instances**:\n to share volumes, you need to share a Shared VPC from a host project\n with multiple service projects. Storage pools created on the Shared VPC\n from the service project are accessible to all service projects.\n\n- **VPC private connections only need to be set up once**: the\n private connection must be set up once per VPC. You don't need\n to repeat private connection setup for multiple service projects or regions.\n\n- **You must assign a CIDR range**: Classless Inter-Domain Routing (CIDR)\n ranges let you represent IP addresses and their corresponding networks for the\n service to use. The service uses IP addresses from the assigned CIDR range to\n assign volumes to the correct protocol type\n (Network File System (NFS) or Server Message Block (SMB)).\n\n- **You must set up the private service access peering before creating your first storage pool**:\n if peering isn't already configured, the storage pool creation process in the\n Google Cloud console detects this and prompts you to set up peering using a\n Google Cloud console based workflow. If a peering connection to the specified\n VPC already exists, the Google Cloud console workflow uses it. For\n both manaul and Google Cloud console based peering, you have the option to either\n manually specify a CIDR or have Google networking pick one for you\n automatically.\n\n- **Choose a CIDR range that doesn't collide with on-premise network CIDR ranges**:\n if you plan to use NetApp Volumes from on-premises networks\n through a VPN or Cloud Interconnect, we strongly recommend that you choose a\n CIDR range that doesn't collide with the CIDR ranges used in your on-premise\n network. If you fail to do so, it can cause IP collisions and routing issues.\n\nConfigure private services access\n---------------------------------\n\nYou can choose to set up private service access later using the UI during\n[storage pool creation](/netapp/volumes/docs/get-started/quickstarts/create-storage-pool)\nor do it manually as described in the following instructions. To learn more\nabout private service access, see [configure private services access](/vpc/docs/configure-private-services-access).\n\n1. **Choose a CIDR range** : NetApp Volumes uses\n [RFC 1918](https://www.rfc-editor.org/rfc/rfc1918)\n or privately used public IP (PUPI) address ranges, with the exception of\n `6.0.0.0/8` and `7.0.0.0/8`. PUPI supports NFS or SMB volumes and NFS or\n SMB clients accessing the volumes. When you use PUPI addresses, use the Google Cloud CLI\n commands instead of the Google Cloud console to set up networking.\n\n You can choose to have private services access automatically select an unused\n CIDR range or specify it manually. Manual selection lets you choose a\n specific address range.\n\n Pick a CIDR range that is large enough to accommodate your volumes and pools.\n The minimum CIDR range you can use is `/24`. NetApp Volumes\n consumes subranges out of the assigned CIDR according to the following rule\n set:\n - Storage pools require a minimum of `/28` subrange.\n\n - Standard, Premium, and Extreme service level volumes are able to share a\n single IP address, even if they are in different storage pools. Therefore,\n a large number of volumes and pools can share a single `/28` subrange.\n Depending on the storage pool parameters like CMEK, LDAP, Active Directory\n policy, and more, volumes will consume more IPs.\n\n - Every Flex service level storage pool requires its own IP address\n with all of its volumes using that same IP address. Therefore, you can\n have 12 storage pools in a `/28` subrange since every subnet has four\n [unusable IP addresses](/vpc/docs/subnets#unusable-ip-addresses-in-every-subnet).\n\n - Large capacity volumes (in Preview) in Extreme service level require a\n `/27` subrange to support multiple storage endpoints.\n\n - Volumes in different regions in the same project require additional `/28`\n or `/27` ranges depending on the kind of volumes you deploy.\n\n - Volumes in different service projects in the same Shared VPC\n require individual `/28` or `/27` ranges. Therefore, the minimum\n sized CIDR range of `/24` can accommodate a maximum of 16 region-service\n project combinations.\n\n - If an existing subrange runs out of IPs, additional subranges can be\n consumed, even for identical project, VPC, or region\n combinations.\n\n2. **Enable the Service Networking API** : make sure that you enable the\n `servicenetworking.googleapis.com` API.\n\n [Enable the API](https://console.cloud.google.com/apis/library/servicenetworking.googleapis.com)\n3. **Set up private services access** : use the following instructions to set up\n private services access using [Google Cloud CLI](/sdk/gcloud):\n\n 1. Reserve a static internal IP address range for your CIDR:\n\n ```bash\n gcloud compute addresses create netapp-addresses-production-vpc1 \\\n --project=PROJECT_ID \\\n --global \\\n --purpose=VPC_PEERING \\\n --prefix-length=24 \\\n --network=VPC \\\n --no-user-output-enabled\n ```\n\n Replace \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e with the name of the project\n you intend to set up private services access in.\n\n This command chooses the base address for the CIDR automatically. If you\n want to specify a specific base address, include the following line: \n\n ```bash\n --addresses=192.168.0.0 \\\n ```\n\n Replace \u003cvar translate=\"no\"\u003e192.168.0.0\u003c/var\u003e with the base address you\n intend to set up private services access for.\n 2. Run the following command to peer the networks:\n\n ```bash\n gcloud services vpc-peerings connect \\\n --project=PROJECT_ID \\\n --service=netapp.servicenetworking.goog \\\n --ranges=netapp-addresses-production-vpc1,ADDITIONAL_IP_RANGES \\\n --network=VPC\n ```\n\n Replace \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e with the name of the project\n you intend to set up private services access in.\n\n You can specify multiple compute address ranges as a comma-separated\n list for the **--ranges** flag. NetApp Volumes use `/28`\n or `/27` subranges from the compute address ranges in an undefined order.\n\n Replace \u003cvar translate=\"no\"\u003eADDITIONAL_IP_RANGES\u003c/var\u003e\n with a comma-separated list of additional address ranges to peer, or\n leave it empty to peer the networks only with the address range created\n in the previous step.\n | **Important:** If peering fails and you receive a `Constraint constraints/compute.restrictVpcPeering violated for project` error, it means your Google Cloud organization policies restrict peering. To resolve this, work with your organization administrator to get an exception.\n 3. Enable custom route propagation. Note that NetApp Volumes\n creates a `sn-netapp-prod` peering when the private connection is set up.\n\n ```bash\n gcloud compute networks peerings update sn-netapp-prod \\\n --project=PROJECT_ID \\\n --network=VPC \\\n --import-custom-routes \\\n --export-custom-routes\n ```\n\n Replace \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e with the name of the project\n you intend to set up private services access in.\n\nWhat's next\n-----------\n\nSet up [IAM permissions](/netapp/volumes/docs/get-started/configure-access/iam)."]]
