Adding initiator nodes

Virtual Storage Platform One SDS Cloud GCP Data Migration
Version
1.19.x
Audience
anonymous
Part Number
MK-24VSP1SDS033-03
ft:lastEdition
2026-04-07

  • Required role: Service and Storage

Note on the procedure

  • Run Terraform in an environment that can support the execution.

Note:

  • When configuring a storage cluster, if you reuse an existing virtual network instead of creating a new one, old rules might remain in the Google Cloud VPC firewall.

    These are old rules automatically added to the Google Cloud VPC firewall by VSP One SDS Block when the storage cluster was previously operational.

    If old rules remain, storage node addition might fail. Therefore, see Deleting rules on a VPC firewall (Cloud for Google Cloud) in the VSP One SDS Block and SDS Cloud System Administration and delete the old rules.

    When deleting old rules, be careful not to accidentally delete new rules added after the storage cluster configuration was completed. You can identify whether a rule is new by the storage node ID included in the rule name.

  1. See Exporting configuration files (Cloud for Google Cloud) in the VSP One SDS Block and SDS Cloud System Administration to obtain configuration files for adding initiator nodes from VSP One SDS Block.

    When exporting configuration files, specify "AddInitiatorNode" for the exportFileType parameter by using a REST API, and specify machineImageId parameter. For Multi-Zone configuration, also specify the zone parameter. This step is mandatory and ensures that you use the latest configuration files.

    CAUTION:

    • Specify the name of a VM image that matches the storage software version for the machineImageId parameter. For the VM image name to specify, refer to VM image name (Cloud for Google Cloud) in the VSP One SDS Block and SDS Cloud System Administration.

    • When the storage cluster applies Multi-Zone configuration, specify the zone parameter for "POST/v1/objects/configuration-file/actions/create/invoke." Obtain the information (zone ID) to specify from fault domain information.

      You can use the following commands to verify fault domain information.

      REST API: GET /v1/objects/fault-domains

      CLI: fault_domain_list

    • If you add initiator nodes in an Zone different from the Zone of an Google Cloud Hyperdisk, data migration performance is degraded.

    • When you specify "AddInitiatorNode" for the exportFileType parameter for configuration file export, use the REST API because CLI commands are unavailable.

    • The zone parameter to be specified for "POST/v1/objects/configuration-file/actions/create/invoke" is not indicated in the VSP One SDS Block and SDS Cloud REST API Reference and VSP One SDS Block and SDS Cloud CLI Reference. See the following Note.

    Note:

    • When the storage cluster applies Multi-Zone configuration, specify the zone ID for the zone parameter.

      Use "physicalZone" of fault domain information as the zone ID.

      [REST API]

      "zone": "<ID-of-zone-in-which-initiator-node-is-to-be-added>"

    • Do not create an initiator node in a fault domain to which tiebreaker nodes belong. Doing so will incur additional data migration costs due to unnecessary communication between different zones.

  2. See Deploying VM configuration files in the Terraform working directory (Cloud for Google Cloud) in the VSP One SDS Block and SDS Cloud System Administration to unzip the configuration file, and then deploy the obtained files.
    CAUTION:

    Make sure you do not edit the unzipped configuration files unless instructed to do so by the manual. If you edit these files, a problem such as storage cluster blockage might occur.

  3. Verify the impact of deploying configuration files for adding initiator nodes.

    Run the following command.

    terraform plan

    When you run the command, the message Terraform will perform the following actions appears, followed by the contents of resource changes.

    Verify that the following resource changes are performed.

    Resource

    Resource manipulation

    Resource name

    Confirmation details

    google_compute_instance.initiator_instance[ ]

    create

    <clusterName>-initiatornode

    One resource is created.

    google_compute_instance.instance[ ]

    update in-place

    <clusterName>-snXX

    If a change is made in the following item, there is no problem.

    • metadata
  4. If there is no problem as a result of confirmation by using the terraform plan command, create an initiator node resource.

    Run the following command.

    terraform apply

    When [Enter a value:] is displayed after running the command, enter [yes].

    If [Apply complete!] is output after running the command, there is no problem.

  5. Add an initiator node.

    You can perform this only for the cluster master node (primary) or a load balancer.

    REST API: POST /v1/objects/storage-nodes

    CLI: storage_node_add

    After executing the above command, you will be asked to enter the setup user's password. At that time, press the Enter key without entering anything.

    Verify the job ID that is displayed after the command is run.

    Note:

    • When the job has finished, additional event log information might be uploaded to the Cloud Storage. If the event log instructs you to see the "Error message file", obtain the additional information from the Cloud Storage based on the path to the error message file indicated in the message.

      The Cloud Storage directory to which the information is uploaded is the directory specified for gsUri in the terraform.tfvars file during storage cluster configuration.

      For information on gsUri, Verify the key for gsUri in terraform output command.

      terraform output
    • The following resource is created with the fixed resource name.

      Resource

      Resource name

      Initiator node

      Initiator node
    • Termination protection is not enabled for an initiator node.
  6. Verify the state of the job.

    Run either of the following commands with the job ID specified.

    REST API: GET /v1/objects/jobs/<jobid>

    CLI: job_show

    After running the command, if you receive a response indicating "Succeeded" as the state, the job is completed.

    Until storage node addition is completed, other operations might not be possible. If any other operation is unsuccessful, take action according to the error message or event log for that operation.

  7. Register information about the migration destination server.

    Run either of the following commands with the nicknames of the intended compute nodes and the type of the OS running on the compute nodes specified.

    Conventions to be followed when setting a nickname:

    • Number of characters: 1 to 229
    • Characters that can be used: Numbers (0 to 9), uppercase alphabet (A to Z), lowercase alphabet (a to z), symbols (\ . : @ _) for the first character. In addition to these, a hyphen (-) can be used for the second and subsequent characters.
    • Each compute node must have a unique nickname.

    REST API: POST /v1/objects/servers

    CLI: server_create

    Verify the job ID which is displayed after the command is run.

  8. Verify the state of the job.

    Run either of the following commands with the job ID specified.

    REST API: GET /v1/objects/jobs/<jobId>

    CLI: job_show

    After running the command, if you receive a response indicating "Succeeded" as the state, the job is completed.

  9. Obtain a list of compute nodes and verify that the information about the intended compute nodes is registered.

    REST API: GET /v1/objects/servers

    CLI: server_list

  10. Verify the initiator name (iSCSI name or host NQN) of the applicable compute node.

    For details, see the documentation for the OS used on the compute node.

  11. Verify that the initiator name (iSCSI name or host NQN) verified in step 10 is not the same as the initiator name (iSCSI name or host NQN) of another compute node.

    If they are the same, change the initiator name (iSCSI name or host NQN).

  12. Verify the ID of the applicable compute node.

    If you use the CLI to specify a compute node by nickname, check the nickname of the compute node.

    REST API: GET /v1/objects/servers

    CLI: server_list

  13. Register information about the intended initiator.

    Run either of the following commands with the ID of the compute node, connection protocol for the initiator, and iSCSI or host NQN name of the initiator.

    If you use the CLI, you can specify a nickname instead of the compute node ID.

    REST API: POST /v1/objects/servers/<id>/hbas

    CLI: hba_create

    Verify the job ID which is displayed after the command is run.

  14. Verify the state of the job.

    Run either of the following commands with the job ID specified.

    REST API: GET /v1/objects/jobs/<jobId>

    CLI: job_show

    After running the command, if you receive a response indicating "Succeeded" as the state, the job is completed.

  15. Obtain a list of information about initiators and verify that the information about the intended initiator is registered.

    Run either of the following commands with the compute node ID specified.

    If you use the CLI, you can specify a nickname instead of the compute node ID.

    REST API: GET /v1/objects/servers/<id>/hbas

    CLI: hba_list

  16. Register path information about the migration destination server.

    Verify the ID of the intended compute node. If you use the CLI to specify a compute node by nickname, check the nickname of the compute node.

    REST API: GET /v1/objects/servers

    CLI: server_list

  17. When you specify the hbaId parameter, verify the ID of the initiator for the intended compute node.

    Run either of the following commands with the compute node ID specified.

    If you use the CLI, you can specify a nickname instead of the compute node ID.

    REST API: GET /v1/objects/servers/<id>/hbas

    CLI: hba_list

  18. When you specify the portId parameter, verify the ID of the compute port to be allocated to the intended compute node.

    REST API: GET /v1/objects/ports

    CLI: port_list

  19. Register compute node path information.

    Run either of the following commands with the compute node ID specified.

    If you use the CLI, you can specify a nickname instead of the compute node ID. Also, you can specify the allocation-destination compute port by using the WWN or iSCSI name instead of the ID.

    REST API: POST /v1/objects/servers/<id>/paths

    CLI: path_create

    Verify the job ID which is displayed after the command is run.

  20. Verify the state of the job.

    Run either of the following commands with the job ID specified.

    REST API: GET /v1/objects/jobs/<jobId>

    CLI: job_show

    After running the command, if you receive a response indicating "Succeeded" as the state, the job is completed.

  21. Obtain a list of path information and verify that the intended path information is added.

    Run either of the following commands with the compute node ID specified.

    If you use the CLI, you can specify a nickname instead of the compute node ID.

    REST API: GET /v1/objects/servers/<id>/paths

    CLI: path_list

  22. Attach the migration-target Google Cloud Hyperdisks (31 at maximum) to the Compute Engine of the initiator node by using the Google Cloud Console.

    The Google Cloud Hyperdisks are mapped within VSP One SDS Block, and external volumes and virtual volumes are created.

    CAUTION:

    • If the project to which the migration-target Google Cloud Hyperdisks belong is different from the project for which a storage cluster was configured, the migration-target Google Cloud Hyperdisks cannot be directly attached to the Compute Engine of the initiator node. In this case, copy the Google Cloud Hyperdisks to the project for which a storage cluster was configured, and then attach the Google Cloud Hyperdisks.

    • For the number of Google Cloud Hyperdisks that can be attached simultaneously, see Detailed specifications.

      If you intend to migrate more Google Cloud Hyperdisks than the maximum number, repeat the migration operation for no more than 31 Google Cloud Hyperdisks per migration (from step 22 of Adding initiator nodes to step 9 of Performing data copy).

    • You can set whether to enable or disable the data reduction function of the migration-destination volume at the time of data copy, but the same values are applied to the all Google Cloud Hyperdisks attached in this procedure. Therefore, if you migrate data by the data reduction function setting multiple times, repeat the migration operation for each setting (from step 22 of Adding initiator nodes to step 9 of Performing data copy ).

    • You can specify the migration-destination fault domain at the time of data copy, but all the Google Cloud Hyperdisks attached in this procedure are migrated to the same fault domain. Therefore, if you migrate data by a migration-destination fault domain multiple times, repeat the migration operation for each fault domain (from step 22 of Adding initiator nodes to step 9 of Performing data copy ).

    • Attach only migration-target Google Cloud Hyperdisks. Before attaching the Google Cloud Hyperdisks, verify that they are correct migration targets. If you have attached Google Cloud Hyperdisks other than the migration-target Google Cloud Hyperdisks, detach the Google Cloud Hyperdisks. Then, according to step 10 in Stopping data migration, delete the external volumes and virtual volumes that correspond to the wrongly attached Google Cloud Hyperdisks.

    • To collect dump files for initiator nodes by using the REST API/CLI, add the option that skips server certificate verification.

      REST API: --insecure

      CLI: --ignore_certificate_errors

  23. Wait approximately 20 seconds, and then verify that external volumes and virtual volumes corresponding to the Google Cloud Hyperdisks that were added in step 22 have been created.

    Verify the volume IDs of the newly created external volumes according to Obtaining a list of external volume information. Also, obtain a list of volume information (see Obtaining a list of volumes in the VSP One SDS Block and SDS Cloud System Administration) to verify the nicknames of the virtual volumes that have the same IDs as the volume IDs of the external volumes. Verify that the obtained information matches the disk names of the migration-target Google Cloud Hyperdisks added in step 22.

    Note:

    The name of the virtual volume is "Volume+<volumeNumber>." This number might start from the 10000s.

  24. Set up a path between the virtual volume and the migration destination server.

    Set up a path to the virtual volume created in step 22.

    See Allocating volumes to compute nodes (Cloud) in the VSP One SDS Block and SDS Cloud System Administration.

    CAUTION:

    • When setting both normal volume and virtual volume paths on the same destination server, assign a normal volume to the lower-numbered LUN and assign a higher-numbered LUN to the virtual volume.

      If a number higher than the LUN of the virtual volume is assigned to a normal volume, the server might not be able to recognize the normal volume as well as the virtual volume as follows. In such a case, review the LUN assignment.

      • Depending on the type of OS installed on the server, the following might occur.

        • When recognizing LUNs in ascending order of LUN numbers, if the server encounters an unrecognizable LUN, it gives up recognizing the subsequent LUNs.

        • When the server cannot recognize LUN of LUN=0, it does not recognize the subsequent LUNs.

      • The server cannot recognize virtual volumes after you perform step 24 until step 4 of Performing data copy.

    • This step is required to perform I/O from the migration destination server to the virtual volumes during data copy. This step cannot be performed after step 2 of Performing data copy has been performed.

    • The virtual volume settings cannot be edited. When you edit the QoS settings, complete step 7 of Performing data copy before doing so.

    Note:

    Step 24 cannot be performed during the time after data copy has been started until completion of data copy has been confirmed (steps 2 through 7 of Performing data copy).

    CAUTION:

    If an I/O operation is performed to virtual volumes during data copy, data of the I/O operation is not copied to the migration destination. Therefore, make sure that I/O operations to the disk to be migrated have stopped before performing data copy.