Gestion des volumes

Vous pouvez souhaiter modifier la forme d'instance de calcul tout en utilisant le même volume d'initialisation. Lorsque vous mettez fin à l'instance, vous pouvez conserver le volume d'initialisation associé et l'utiliser pour créer une instance avec une forme ou un type différent. Cette approche est utile pour les scénarios dans lesquels la forme de l'instance ne peut pas être modifiée lors du redimensionnement des instances.

Pour ce faire, vous devez détacher le volume d'initialisation de l'instance en cours d'exécution. Cette opération peut être effectuée soit en mettant fin à l'instance tout en conservant le volume d'initialisation, soit en arrêtant l'instance et en détachant le volume d'initialisation.

Pour toutes les ressources Terraform de type oci_core_instance, le paramètre preserve_boot_volume est défini sur true par défaut. Ce paramètre garantit que si vous mettez fin à l'instance, vous ne mettez pas fin au volume d'initialisation attaché.

resource "oci_core_instance" "TFInstance" {
  ...
  state = "STOPPED"                  // set this state to stop the instance
  preserve_boot_volume = true
}

output "bootVolumeFromInstance" {
  value = [oci_core_instance.TFInstance.boot_volume_id]
}

Une fois le volume d'initialisation détaché, son OCID peut être considéré comme la source de la nouvelle instance, comme suit :

resource "oci_core_instance" "TFScaleInstance" {
  ...
  source_details {
    source_type = "bootVolume"

    // reference the original boot volume id here
    source_id   = "ocid1.bootvolume.oc1.phx.exampleuniqueID"   
  }
}

Si vous pensez qu'un problème de volume d'initialisation est à l'origine d'un problème d'instance de calcul, vous pouvez arrêter l'instance et détacher le volume d'initialisation. Vous pouvez ensuite l'attacher à une autre instance en tant que volume de données pour résoudre le problème. Une fois le problème résolu, vous pouvez l'attacher à nouveau à l'instance d'origine ou l'utiliser pour lancer une nouvelle instance.

Une fois le volume d'initialisation détaché, son OCID peut être considéré comme le paramètre de volume de blocs pour une autre instance.

resource "oci_core_volume_attachment" "TFBlockAttach" {
  ...
  attachment_type = "iscsi"
  compartment_id  = "ocid1.compartment.oc1..exampleuniqueID"

  // new instance
  instance_id     = "ocid1.instance.oc1.phx.exampleuniqueID"    

  // attach the boot volume as a block volume
  volume_id       = "ocid1.bootvolume.oc1.phx.exampleuniqueID"                                                                                    
}

Après avoir résolu le problème, déconnectez ce volume de la deuxième instance et attachez-le en tant que volume d'initialisation à l'instance d'origine.

resource "oci_core_instance" "TFScaleInstance" {
  ...

  source_details {
    source_type = "bootVolume"

    // attach back as boot volume
    // reference the volume id here
    source_id   = "ocid1.bootvolume.oc1.phx.exampleuniqueID"       
  }
}

Vous pouvez utiliser Terraform pour répliquer les volumes de blocs et d'initialisation d'instance de calcul existants vers un autre domaine de disponibilité au sein de la même région.

Pour répliquer un volume, procédez comme suit :

1. Créez une source de données pour le volume à l'aide de oci_core_boot_volume ou oci_core_volume.
2. Utilisez la ressource oci_core_boot_volume_backup ou oci_core_volume_backup pour créer une sauvegarde du volume source.
3. Définissez la ressource de volume cible à créer à partir de la sauvegarde.

L'exemple de configuration Terraform suivant réplique un volume d'initialisation et un volume de blocs :

provider "oci" {
  region = "us-ashburn-1"
}
 
locals {
  compartment_id = "ocid1.compartment.oc1..exampleuniqueID"
  target_ad = "ilMx:US-ASHBURN-AD-2"
  source_boot_id = "ocid1.bootvolume.oc1.iad.exampleuniqueID"
  source_volume_id = "ocid1.volume.oc1.iad.exampleuniqueID"
}
 
# Boot Volume Clone
data "oci_core_boot_volume" "source" {
  boot_volume_id = local.source_boot_id
}
 
resource "oci_core_boot_volume_backup" "backup" {
  boot_volume_id = data.oci_core_boot_volume.source.id
  type      = "FULL"
}
 
resource "oci_core_boot_volume" "target" {
  availability_domain = local.target_ad
  compartment_id      = local.compartment_id
  source_details {
    id   = oci_core_boot_volume_backup.backup.id
    type = "bootVolumeBackup"
  }
  display_name = "Test Cloned Boot Volume"
}
 
# Block Volume Clone
data "oci_core_volume" "source" {
  volume_id = local.source_volume_id
}
resource "oci_core_volume_backup" "backup" {
  volume_id = data.oci_core_volume.source.id
  type      = "FULL"
}
 
resource "oci_core_volume" "target" {
  availability_domain = local.target_ad
  compartment_id      = local.compartment_id
  source_details {
    id   = oci_core_volume_backup.backup.id
    type = "volumeBackup"
  }
  display_name = "Test Cloned Block Volume"
}

Vous pouvez utiliser ces étapes pour déplacer une instance vers le deuxième domaine de disponibilité ou pour créer un déploiement de récupération après sinistre dans le deuxième domaine de disponibilité.

Si cette méthode est utilisée pour un scénario de retargeting pur dans lequel les volumes source (et les sauvegardes) sont enlevés après la duplication, la configuration Terraform doit être remaniée après la suppression des volumes source afin d'éviter la destruction des instances cible lors de la prochaine application.

Si vous utilisez ce scénario sur une base de données de secours à froid pour la récupération après sinistre, vous pouvez régulièrement exécuter la commande Terraform taint pour marquer le volume à des fins de destruction et de recréation lors de la prochaine application de la configuration.