diff --git a/docs/products/compute/compute-instances/_index.md b/docs/products/compute/compute-instances/_index.md index 4c0f384af35..b3cf51a1f86 100644 --- a/docs/products/compute/compute-instances/_index.md +++ b/docs/products/compute/compute-instances/_index.md @@ -49,6 +49,7 @@ Linode bundles the following services with all Compute Instances: - Domain management through our [DNS Manager](https://www.linode.com/products/dns-manager/) - Seamless firewall management with [Cloud Firewalls](https://www.linode.com/products/cloud-firewall/) - Private Layer 2 networks with [VLANs](https://www.linode.com/products/vlan/) +- Physical placement of your Compute Instances in a data center with [Placement Groups](/docs/products/compute/compute-instances/guides/placement-groups/) - Metrics and monitoring through the [Cloud Manager](https://www.linode.com/products/monitoring/) and [Longview](/docs/products/tools/longview/) (free plan) - Reusable deployment scripts through [StackScripts](https://www.linode.com/products/stackscripts/) diff --git a/docs/products/compute/compute-instances/guides/_index.md b/docs/products/compute/compute-instances/guides/_index.md index ca9641bee80..ef4eb4ec884 100644 --- a/docs/products/compute/compute-instances/guides/_index.md +++ b/docs/products/compute/compute-instances/guides/_index.md @@ -2,7 +2,7 @@ title: Guides title_meta: "Guides and Tutorials for Compute Instances" description: "A collection of guides to help you start deploying Compute Instances and using them to host your web applications and Cloud workloads" -modified: 2024-01-03 +modified: 2024-06-20 tab_group_main: weight: 30 aliases: ['/products/compute/shared-linodes/guides/','/products/compute/shared-cpu/guides/','/products/compute/gpu/guides/','/products/compute/dedicated-cpu/guides/','/products/compute/high-memory/guides/'] @@ -22,6 +22,7 @@ aliases: ['/products/compute/shared-linodes/guides/','/products/compute/shared-c - [Access Your Desktop Environment Using Glish (Linode Graphical Shell)](/docs/products/compute/compute-instances/guides/glish/) - [Reset Root Password](/docs/products/compute/compute-instances/guides/reset-root-password/) - [Clone a Compute Instance](/docs/products/compute/compute-instances/guides/clone-instance/) +- [Physically Group Compute Instances to Meet Your Needs](/docs/products/compute/compute-instances/guides/placement-groups) - [Initiate a Cross Data Center Migration](/docs/products/compute/compute-instances/guides/migrate-to-different-dc/) - [Configure Email Alerts for Resource Usage on Compute Instances](/docs/products/compute/compute-instances/guides/resource-usage-email-alerts/) diff --git a/docs/products/compute/compute-instances/guides/clone-instance/index.md b/docs/products/compute/compute-instances/guides/clone-instance/index.md index 362240b2402..e138d785ff2 100644 --- a/docs/products/compute/compute-instances/guides/clone-instance/index.md +++ b/docs/products/compute/compute-instances/guides/clone-instance/index.md @@ -16,7 +16,7 @@ Linode's cloning feature allows you to duplicate a Compute Instance's disks (and This process copies all disks and configuration profiles to a newly created Compute Instance on your account. {{< note >}} -Before continuing, it's recommended to power off the instance you would like to clone. This helps prevent data corruption. +Before continuing, you should power off the instance you want to clone. This helps prevent data corruption. {{< /note >}} 1. Log in to the [Cloud Manager](https://cloud.linode.com). @@ -30,7 +30,7 @@ Before continuing, it's recommended to power off the instance you would like to 1. Under **Select Linode to Clone From**, search for and select the instance you wish to clone. If the selected instance is running, **Power Off** appears to the right. 1. To help prevent data corruption during cloning, click **Power Off**. - + {{< note >}} If you're using a mobile device, available instances appear as cards without the Power Off option. To power off an instance from a mobile device, go to the instance's details page. {{< /note >}} @@ -38,7 +38,9 @@ Before continuing, it's recommended to power off the instance you would like to 1. Complete the remainder of the form. Enter a label and select the region, the plan, and other options for the new Compute Instance. {{< note >}} - The plan's storage must be greater than the combined disk size of the original instance. If you wish to select a plan with less storage, you may need to [resize your disks](/docs/products/compute/compute-instances/guides/disks-and-storage/) before cloning. + - The plan's storage must be greater than the combined disk size of the original instance. If you wish to select a plan with less storage, you may need to [resize your disks](/docs/products/compute/compute-instances/guides/disks-and-storage/) before cloning. + + - If the target Compute Instance is in a [placement group](/docs/products/compute-instances/guides/placement-groups), the clone isn't automatically included in the same placement group. You need to specify a placement group to include it in. The target placement group needs to have capacity to include a cloned Compute Instance and it needs to be in the same data center as the clone. {{< /note >}} 1. Click the **Create Linode** button to start the cloning process. Cloning a Compute Instance can be much longer than creating a new instance based on a distribution image or custom image. The length of time depends on the size of the disks, among other factors. To keep track of the cloning progress, a status bar is displayed above the original Compute Instance with the percentage of completion. diff --git a/docs/products/compute/compute-instances/guides/copy-a-disk-image-to-a-different-account/add_disk.png b/docs/products/compute/compute-instances/guides/copy-a-disk-image-to-a-different-account/add_disk.png index ccbc84b3c27..7f444695eff 100644 Binary files a/docs/products/compute/compute-instances/guides/copy-a-disk-image-to-a-different-account/add_disk.png and b/docs/products/compute/compute-instances/guides/copy-a-disk-image-to-a-different-account/add_disk.png differ diff --git a/docs/products/compute/compute-instances/guides/copy-a-disk-image-to-a-different-account/block-device-assignment.png b/docs/products/compute/compute-instances/guides/copy-a-disk-image-to-a-different-account/block-device-assignment.png index d106a69ca44..917affa51e5 100644 Binary files a/docs/products/compute/compute-instances/guides/copy-a-disk-image-to-a-different-account/block-device-assignment.png and b/docs/products/compute/compute-instances/guides/copy-a-disk-image-to-a-different-account/block-device-assignment.png differ diff --git a/docs/products/compute/compute-instances/guides/copy-a-disk-image-to-a-different-account/boot-this-config.png b/docs/products/compute/compute-instances/guides/copy-a-disk-image-to-a-different-account/boot-this-config.png index 3f44059ede3..82d3262e2b3 100644 Binary files a/docs/products/compute/compute-instances/guides/copy-a-disk-image-to-a-different-account/boot-this-config.png and b/docs/products/compute/compute-instances/guides/copy-a-disk-image-to-a-different-account/boot-this-config.png differ diff --git a/docs/products/compute/compute-instances/guides/copy-a-disk-image-to-a-different-account/image-selection.png b/docs/products/compute/compute-instances/guides/copy-a-disk-image-to-a-different-account/image-selection.png index ba9d61b4a7b..15193f7bba9 100644 Binary files a/docs/products/compute/compute-instances/guides/copy-a-disk-image-to-a-different-account/image-selection.png and b/docs/products/compute/compute-instances/guides/copy-a-disk-image-to-a-different-account/image-selection.png differ diff --git a/docs/products/compute/compute-instances/guides/copy-a-disk-image-to-a-different-account/index.md b/docs/products/compute/compute-instances/guides/copy-a-disk-image-to-a-different-account/index.md index 072cc4c4636..0063189cfb7 100644 --- a/docs/products/compute/compute-instances/guides/copy-a-disk-image-to-a-different-account/index.md +++ b/docs/products/compute/compute-instances/guides/copy-a-disk-image-to-a-different-account/index.md @@ -3,7 +3,7 @@ title: "Copying a Disk to a Different Account" title_meta: "How to Copy a Disk to a Different Account" description: "Review this guide to find out how to copy a disk of a Linode from one Linode account to another." published: 2020-06-01 -modified: 2022-03-28 +modified: 2024-06-20 keywords: ["disk", "migration", "moving to different accounts"] tags: ["linode platform","cloud manager"] image: copying_a_disk_to_a_differnet_account_smg.png @@ -13,7 +13,7 @@ aliases: ['/migration/copy-disk-image-different-account/','/linode-platform/mana You can copy a disk of a Linode from one Linode account to another. This is a great way to prepare a disk for another Linode customer and transfer it from one individual account to another individual account. Or if you have multiple Linode accounts, this guide provides instructions to consolidate all the disks in one account. {{< note >}} -If you are copying a disk of a Linode that hosts applications, then ensure that you complete the backup and migrate steps for the respective applications. +If you're copying a disk from a Linode that hosts applications, then ensure that you complete the backup and migrate steps for the respective applications. {{< /note >}} ## Preparing the Receiving Linode @@ -23,18 +23,20 @@ You need to prepare the *receiving* Linode before initiating the transfer. First ### Creating a New Receiving Linode 1. Log in to the [Cloud Manager](https://cloud.linode.com) with the username and password you created when signing up. + 1. Click **Create** at the top of the page and select **Linode**. + 1. Click **X** to not choose any **Image** in the **Choose a Distribution** section of the [Distributions](/docs/products/compute/compute-instances/guides/distributions/) tab. ![Creating a receiving Linode](image-selection.png) -1. Choose the region where you would like the Linode to reside. If you're not sure which to select, see our [How to Choose a Data Center](/docs/products/platform/get-started/guides/choose-a-data-center/) guide. You can also generate [MTR reports](/docs/guides/diagnosing-network-issues-with-mtr/) for a deeper look at the route path between you and a data center in each specific region. +1. Choose the region where you would like the Linode to reside. If you're not sure which to select, see our [How to Choose a Data Center](/docs/products/platform/get-started/guides/choose-a-data-center/) guide. You can also generate [MTR reports](/docs/guides/diagnosing-network-issues-with-mtr/) for a deeper look at the route path between you and a data center in each specific region. -1. Select a Linode plan. +1. Select a Linode plan. 1. Give the Linode a label. This is a name to help you easily identify it within the Cloud Manager's Dashboard. If desired, assign a tag to the Linode in the **Add Tags** field. -1. Skip the **Root Password** and **SSH Keys** fields, as they are disabled when creating an empty Linode. +1. Skip the **Root Password** and **SSH Keys** fields, as they are disabled when creating an empty Linode. 1. Click **Create Linode**. The system directs you to the *Linodes* page that reports the status of the Linode as it boots up. @@ -46,14 +48,17 @@ To hold the files transferred from the other Linode, create two new disks labele 1. Go to the **Storage** tab and click **Add a Disk** in the **Disks** section. The **Add Disk** window appears. - ![Adding a disk](add_disk.png) + ![Creating a receiving Linode](add_disk.png) 1. Type a descriptive name such as `copy` for the disk in the **Label** field. + 1. Select `ext4` in the **Filesystem** dropdown field. + 1. Set the size of the disk in the **Size** field. The size of the disk must be large enough to hold the contents of the disk that you want to copy. + 1. Click **Add** to create the disk. -1. Repeat the steps to create a disk labeled `swap` and select `swap` in the **Filesystem** dropdown field. - Ensure that the size of the `swap` disk is the same as that of the `swap` disk of the disk that you want to copy. + +1. Repeat the steps to create a disk labeled `swap` and select `swap` in the **Filesystem** dropdown field. Ensure that the size of the `swap` disk is the same as that of the `swap` disk of the disk that you want to copy. The system creates disks to hold the files from the disk of other account. @@ -61,10 +66,13 @@ The system creates disks to hold the files from the disk of other account. Start the receiving Linode in rescue mode: -1. Select the Linode that is receiving the disk. The Linode's dashboard appears. +1. Select the Linode that is receiving the disk. The Linode's dashboard appears. + 1. Select the **More Options Ellipsis** and click the **Rescue** button. -1. Set the **/dev/sda** field to `copy` and **/dev/sdb** to `swap`. -1. Click **Reboot into Rescue Mode**. + +1. Set the **/dev/sda** field to `copy` and **/dev/sdb** to `swap`. + +1. Click **Reboot into Rescue Mode**. ### Access the Linode in Rescue Mode diff --git a/docs/products/compute/compute-instances/guides/create/create-instance-pg.png b/docs/products/compute/compute-instances/guides/create/create-instance-pg.png new file mode 100644 index 00000000000..7c574f94ebc Binary files /dev/null and b/docs/products/compute/compute-instances/guides/create/create-instance-pg.png differ diff --git a/docs/products/compute/compute-instances/guides/create/index.md b/docs/products/compute/compute-instances/guides/create/index.md index d4b1caf1517..0576aa74da1 100644 --- a/docs/products/compute/compute-instances/guides/create/index.md +++ b/docs/products/compute/compute-instances/guides/create/index.md @@ -3,26 +3,27 @@ title: "Create a Compute Instance" title_meta: "Create a Compute Instance on the Linode Platform" description: "Learn how to create a new Compute Instance, including choosing a distribution, region, and plan size." published: 2022-04-19 -modified: 2024-05-21 +modified: 2024-06-20 keywords: ["getting started", "deploy", "linode", "linux"] aliases: ['/guides/creating-a-compute-instance/','/products/compute/dedicated-cpu/guides/deploy/'] --- This guide walks you through creating a Compute Instance (also frequently called a *Linode*) through the Cloud Manager. Whether this is your first time using Linode or if you're a long time user, you should carefully consider each step in the process to make sure you're getting the most of your Linode services. -1. [Open the Create Form in the Cloud Manager](#open-the-create-form-in-the-cloud-manager) -1. [Choose a Distribution, App, or Image](#choose-a-distribution-app-or-image) -1. [Select a Region](#select-a-region) -1. [Choose an Instance Type and Plan](#choose-an-instance-type-and-plan) -1. [Set the Label and Add Tags](#set-the-label-and-add-tags) -1. [Create a Password and Add SSH Keys](#create-a-password-and-add-ssh-keys) -1. [Assign to a VPC](#assign-to-a-vpc) -1. [Assign to a Cloud Firewall](#assign-to-a-cloud-firewall) -1. [Assign to a VLAN](#assign-to-a-vlan) -1. [Configure Additional Options](#configure-additional-options) -1. [Add User Data](#add-user-data) -1. [Deploy the Instance](#deploy-the-instance) -1. [Getting Started After Deployment](#getting-started-after-deployment) +- [Open the Create Form in the Cloud Manager](#open-the-create-form-in-the-cloud-manager) +- [Choose a Distribution, App, or Image](#choose-a-distribution-app-or-image) +- [Select a Region](#select-a-region) +- [Choose an Instance Type and Plan](#choose-an-instance-type-and-plan) +- [Set the Label and Add Tags](#set-the-label-and-add-tags) +- [Create a Password and Add SSH Keys](#create-a-password-and-add-ssh-keys) +- [Assign to a VPC (Optional) {#assign-to-a-vpc}](#assign-to-a-vpc-optional-assign-to-a-vpc) +- [Assign to a Cloud Firewall (Optional) {#assign-to-a-cloud-firewall}](#assign-to-a-cloud-firewall-optional-assign-to-a-cloud-firewall) +- [Assign to a VLAN (Optional) {#assign-to-a-vlan}](#assign-to-a-vlan-optional-assign-to-a-vlan) +- [Assign to a Placement Group (Optional) {#assign-to-a-placement-group}](#assign-to-a-placement-group-optional-assign-to-a-placement-group) +- [Configure Additional Options](#configure-additional-options) +- [Add User Data](#add-user-data) +- [Deploy the Instance](#deploy-the-instance) +- [Getting Started After Deployment](#getting-started-after-deployment) ## Open the Create Form in the Cloud Manager @@ -130,6 +131,16 @@ Add this Compute Instance to a secure private network. VLANs are available at no In most cases, it's recommended to use a VPC over a VLAN. VPCs operate on a higher network layer and come with more IP addressing and IP routing functionality. Additionally, you can further segment out network traffic through subnets, each of which has its own CIDR range. Review [these differences](/docs/products/networking/vpc/#difference-between-private-network-options-vpcs-vlans-and-private-ips) to learn more. {{< /note >}} +## Assign to a Placement Group (Optional) {#assign-to-a-placement-group} + +![Creating a receiving Linode](create-instance-pg.png) + +Add this Compute Instance to a Placement Group to manage its physical location in a data center ("region"). Placement Groups can be set up to group your compute instances close together to help with performance, or further apart to support high availability. Placement Groups are available at no additional cost, but they're not available in all regions. See [Work with Placement Groups](/docs/products/compute-instances/guides/placement-groups) to learn more. + +{{< note >}} +If you don't have an existing Placement Group, you can click **Create Placement Group** to create a new one. This takes you to a separate interface, outside creating your compute instance. For ease of use, create your compute instances in a supported region, then later create a Placement Group and assign your compute instances to it. +{{< /note >}} + ## Configure Additional Options The following features and services can be configured during the Compute Instance's creation or at any point after. diff --git a/docs/products/compute/compute-instances/guides/failover/index.md b/docs/products/compute/compute-instances/guides/failover/index.md index 59f2cfea75e..68175b54d05 100644 --- a/docs/products/compute/compute-instances/guides/failover/index.md +++ b/docs/products/compute/compute-instances/guides/failover/index.md @@ -2,7 +2,7 @@ title: "Configure Failover on a Compute Instance" description: "This guide discusses how to enable failover on a Linode Compute Instance through using our IP Sharing feature with software such as keepalived or FRR." published: 2022-03-23 -modified: 2024-02-20 +modified: 2024-06-20 keywords: ['IP failover','IP sharing','elastic IP'] aliases: ['/guides/ip-failover/'] tags: ["media"] @@ -53,11 +53,8 @@ Within Linode's platform, failover is configured by first enabling [IP Sharing]( | Washington, DC (USA) | **Supported** | BGP-based (new) | [lelastic](/docs/products/compute/compute-instances/guides/failover/#configure-failover) / [FRR](/docs/products/compute/compute-instances/guides/failover-bgp-frr/) | 17 | {{< note >}} -If a data center is marked as *undergoing network upgrades*, customers may encounter issues enabling IP Sharing and configuring failover. For Compute Instances that already have IP Sharing enabled, this feature should still function as intended. Once the network upgrades are completed, IP Sharing will be supported through the new method (BGP). Review documentation on our [planned network infrastructure upgrades](/docs/products/compute/compute-instances/guides/network-infrastructure-upgrades/) to learn more about these changes. -{{< /note >}} - -{{< note >}} -IP failover for VLAN IP addresses is supported within every data center where VLANs are available. This feature does not depend on Linode's IP Sharing feature and depends on ARP-based failover software, such as keepalived. +- If a data center is marked as *undergoing network upgrades*, customers may encounter issues enabling IP Sharing and configuring failover. For Compute Instances that already have IP Sharing enabled, this feature should still function as intended. Once the network upgrades are completed, IP Sharing will be supported through the new method (BGP). Review documentation on our [planned network infrastructure upgrades](/docs/products/compute/compute-instances/guides/network-infrastructure-upgrades/) to learn more about these changes. +- IP failover for VLAN IP addresses is supported within every data center where VLANs are available. This feature does not depend on Linode's IP Sharing feature and depends on ARP-based failover software, such as keepalived. {{< /note >}} ## IP Address Failover Methods @@ -75,18 +72,13 @@ IP failover for VLAN IP addresses is supported within every data center where VL The instructions within this guide enable you to configure failover using IP Sharing and the [lelastic](https://github.com/linode/lelastic) tool, a Linode provided tool based on GoBGP that automates much of the configuration. While lelastic enables many basic implementations of failover, you may want to consider using FRR or any other BGP client if your implementation is more advanced. See [Configuring IP Failover over BPG using FRR](/docs/products/compute/compute-instances/guides/failover-bgp-frr/). {{< note >}} -If your data center supports the legacy method (ARP), use the [Configuring IP Failover using keepalived](/docs/products/compute/compute-instances/guides/failover-legacy-keepalived/) guide instead. That guide should also be used when setting up failover for VLAN IP addresses. +- If your data center supports the legacy method (ARP), use the [Configuring IP Failover using keepalived](/docs/products/compute/compute-instances/guides/failover-legacy-keepalived/) guide instead. That guide should also be used when setting up failover for VLAN IP addresses. +- If you've included your compute instances in a [placement group](/docs/products/compute/compute-instances/guides/placement-groups/), the group needs to use **Anti-affinity** as its Affinity Type, which spreads them out in a data center. The opposite Affinity Type, **Affinity** physically places compute instances close together, sometimes on the same host. This defeats the purpose of fail over. {{< /note >}} -To configure failover, complete each section in the order shown: - -1. [Create and Share the Shared IP Address](#create-and-share-the-shared-ip-address) -1. For *each* Compute Instance: - - [Add the Shared IP to the Networking Configuration](#add-the-shared-ip-to-the-networking-configuration) - - [Install and Configure Lelastic](#install-and-configure-lelastic) -1. [Test Failover](#test-failover) +To configure failover, complete each section that follows. -### Create and Share the Shared IP Address +### 1. Create and Share the Shared IP Address 1. Log in to the [Cloud Manager](https://cloud.linode.com/). @@ -106,7 +98,7 @@ To configure failover, complete each section in the order shown: When IP Sharing is enabled for an IP address, all connectivity to that IP address is immediately lost *until* it is configured on [Lelastic](#install-and-configure-lelastic), [FRR](/docs/products/compute/compute-instances/guides/failover-bgp-frr/), or another BGP routing tool. This is not an issue when adding a new IP address, but should be considered if you are enabling IP Sharing on an existing IP address that is actively being used. {{< /note >}} -### Add the Shared IP to the Networking Configuration +### 2. Add the Shared IP to the Networking Configuration Adjust the network configuration file on *each* Compute Instance, adding the shared IP address and restarting the service. @@ -175,7 +167,7 @@ Adjust the network configuration file on *each* Compute Instance, adding the sha Since the loopback interface is not used, you must also add the `-allifs` option to the lelastic command (discussed in a separate section below). -### Install and Configure Lelastic +### 3. Install and Configure Lelastic Next, we need to configure the failover software on *each* Compute Instance. For this, the [lelastic](https://github.com/linode/lelastic) utility is used. For more control or for advanced use cases, follow the instructions within the [Configuring IP Failover over BPG using FRR](/docs/products/compute/compute-instances/guides/failover-bgp-frr/) guide instead of using lelastic. diff --git a/docs/products/compute/compute-instances/guides/migrate-to-different-dc/index.md b/docs/products/compute/compute-instances/guides/migrate-to-different-dc/index.md index f6ca81afba5..e1229a64e91 100644 --- a/docs/products/compute/compute-instances/guides/migrate-to-different-dc/index.md +++ b/docs/products/compute/compute-instances/guides/migrate-to-different-dc/index.md @@ -1,49 +1,46 @@ --- -title: Initiate a Cross Data Center Migration for a Compute Instance +title: Migrate to a New Data Center description: "Learn how to migrate a Compute Instance across data centers using the Cloud Manager." -published: 2019-02-04 -modified: 2023-09-21 keywords: ["choose", "help", "migration", "data center"] tags: ["linode platform","cloud manager"] +modified: 2024-05-09 +modified_by: + name: Linode +published: 2019-02-04 aliases: ['/platform/disk-images/how-to-initiate-a-cross-data-center-migration-for-your-linode/','/platform/migrating-to-a-different-data-center/','/guides/how-to-initiate-a-cross-data-center-migration-for-your-linode/'] --- -When a Compute Instance is created, it is stored on whichever data center was selected during the creation process. If you wish to change this data center, you can initiate a cross data center migration at any time. This moves your Compute Instance to whichever data center you wish. +When you create a Compute Instance, it's stored on a specific data center you select. If you need to change this, you can initiate a cross-data-center migration, to move it to another data center. {{< note >}} Review the [Choosing a Data Center](/docs/products/platform/get-started/guides/choose-a-data-center/) guide to learn how to choose and speed test a data center. {{< /note >}} -## In this Guide: - -This guide will cover the following topics: - -- [Important details to know before initiating a cross data center migration](#things-to-know-before-migrating). -- [How to migrate your Compute Instance to a different data center](#migrating-to-a-new-data-center). +## Before You Begin -## Things to Know Before Migrating +Various changes applied by the migration can impact your instance's configuration and the devices connected to it. They can all be seen in a caution message before proceeding with your migration within the Cloud Manager. Here are some changes you should be aware of: -Migrating your Compute Instance to a new data center will result in a number of changes that may impact your instance's configuration and external devices connected to it. All of these changes can be seen in a caution message before proceeding with your migration within the Cloud Manager. Changes to be aware of are as follows: +- **IP addresses are not transferrable** They aren't migrated to the new data center with your Compute Instance. Akamai issues a new IPv4 and IPv6 address for your instance, and you can access them once the migration completes. When your instance enters the migration queue, new IP addresses are reserved and you can see them in your instance's **Networking** detail page. See the [Find Your Linode's IP Address](/docs/guides/find-your-linodes-ip-address/) guide to learn how to access Networking information in the Cloud Manager. -- IP addresses are not transferrable across data centers and they will not be migrated with your Compute Instance. Your instance will be issued a new IPv4 and IPv6 address, which will be accessible once the migration completes. When your instance enters the migration queue, new IP addresses are reserved and can be viewed on your instance's **Networking** detail page. See the [Find Your Linode's IP Address](/docs/guides/find-your-linodes-ip-address/) guide to learn how to access Networking information in the Cloud Manager. - -- Any DNS records that point to the original IP address should be changed to use the new IP address once migrated. If you're hosting your DNS with us, this can be done through the [DNS Manager](/docs/products/networking/dns-manager/), while [rDNS](/docs/products/compute/compute-instances/guides/configure-rdns/) can be configured directly on each Compute Instance's Networking detail page. +- **DNS records need to be updated**. You need to update DNS records with the new IP address once migrated. If you're hosting your DNS with us, this can be done through the [DNS Manager](/docs/products/networking/dns-manager/), while [rDNS](/docs/products/compute/compute-instances/guides/configure-rdns/) can be configured directly on each Compute Instance's Networking detail page. {{< note >}} - If any of these DNS records are in use, the software using them will not be able to connect after the migration is completed *until* the DNS records have been upgraded and the changes have propagated. + If any DNS records are in use, the software using them won't be able to connect during or after the migration. After the migration, you need to make the necessary changes to the DNS, and they need to propagate. {{< /note >}} -- Any existing Backups created through our [Linode Backup Service](/docs/products/storage/backups/) will not be migrated. Once the Compute Instance's migration has completed, your backup service will restart on its normal schedule. +- **Existing Backups can't be migrated**. Any [Linode Backup Service](/docs/products/storage/backups/) backup you have scheduled during the migration is skipped. Once the migration completes, Cloud Manager restarts your backup service on its normal schedule. + +- **Block Storage volumes can't be migrated to other data centers**. If you have a Block Storage volume attached to your Compute Instance, the migration detaches it as it begins. See our [Transfer Block Storage Data between Data Centers](/docs/products/storage/block-storage/guides/transfer-volume-data-between-data-centers/) guide to learn how to transfer a Block Storage volume's data between data centers. -- Block Storage volumes cannot be migrated to other regions. If you have a Block Storage volume attached to your Compute Instance, it will be detached when the migration begins. See our [Transfer Block Storage Data between Data Centers](/docs/products/storage/block-storage/guides/transfer-volume-data-between-data-centers/) guide to learn how to transfer a Block Storage volume's data between data centers. +- **Services need to be supported in the target data center**. If the Compute Instance is using IPv6 pools, VLANs, or other features that have not yet been deployed to all data centers, the destination data center needs to support these features, too. Any non-supported service is stripped from the migrated Compute Instance. -- If the Compute Instance is using IPv6 pools, VLANs, or other features that have not yet been deployed to all data centers, the destination data center must also support these features. +- **There is downtime during the migration**. Data transfer requires some time. This downtime varies, based on your total disk size and the speeds expected between each data center. Before the migration, Cloud Manager displays a calculated estimate for this downtime in the "Caution" message. -- Migrations will include a period of downtime while your data is transferred. This estimate varies depending on your total disk size and the speeds expected between each data center. A calculated estimate will be displayed within the "Caution" message displayed before moving forward with your migration. +- **Pricing can vary between data centers**. In some newer data centers, services and network transfer are billed at separate rates due to higher region-based infrastructure costs. Before you migrate from one region to another, confirm any applicable price differences. See our [Pricing](https://www.linode.com/pricing/) page for a list of pricing and plan options. -- Pricing may vary between data centers. Services and network transfer in some newer data centers are billed at separate rates due to higher region-based infrastructure costs. Before you migrate from one region to another, you must confirm any applicable price differences that will occur as a result of the migration. See our [Pricing](https://www.linode.com/pricing/) page for a complete list of pricing and plan options. +- **Migration removes a compute instance from a placement group**. A [placement group](/docs/products/compute/compute-instances/guides/placement-groups/) needs to exist in a specific data center, and its member compute instances need to be in that *same data center*. If the target data center supports them, you can select to create a new placement group during the migration set up. -## Migrating to a New Data Center +## Migrate to a New Data Center 1. Log in to the [Cloud Manager](https://www.cloud.linode.com) and click on the **Linodes** link in the sidebar. @@ -53,12 +50,8 @@ Migrating your Compute Instance to a new data center will result in a number of This same menu also appears within each individual Compute Instance's dashboard page. -1. In **Migrate Linode** form, review the details of the migration and check the **Accept** box to agree to these conditions and expectations. +3. In **Migrate Linode** form, review the details of the migration and check the **Accept** box to agree to these conditions and expectations. -1. Under **Configure Migration**, select the destination region. This will be the data center that the Compute Instance is migrated to. +1. Under **Configure Migration**, select the destination **Region** for the migration. -1. Click on the **Enter Migration Queue** button, which closes the form and enters the Compute Instance into the migration queue. You can monitor the progress of your migration from both within the list of Compute Instances and the Compute Instance's dashboard. Your instance will return to its previous state (powered on or off) once the migration has completed. - -{{< note >}} -If migrating to a data center with different plan pricing, a note will display the difference in price prior to migrating. -{{< /note >}} \ No newline at end of file +1. Click **Enter Migration Queue**. You can monitor the progress of your migration from the list of Compute Instances and the Compute Instance's dashboard. Cloud Manager returns your instance to its previous state (powered on or off) once the migration completes. \ No newline at end of file diff --git a/docs/products/compute/compute-instances/guides/placement-groups/index.md b/docs/products/compute/compute-instances/guides/placement-groups/index.md new file mode 100644 index 00000000000..5aaf6648fb3 --- /dev/null +++ b/docs/products/compute/compute-instances/guides/placement-groups/index.md @@ -0,0 +1,192 @@ +--- +title: "Work with Placement Groups" +description: "Learn how to group your compute instances to best meet your delivery model." +published: 2024-06-20 +keywords: ["placement-group", "affinity", "compliance"] +--- + +When you deploy several compute instances in an Akamai data center ("region"), they're allocated to physical machines. This allocation varies based on several factors, including the compute instance plan and availability for that plan sizes. However, you may want your compute instances in specific physical locations, to best support your need. You may want them close together, even on the same host to speed up performance. Or, you may want to disperse them across several hosts to support high availability. Placement groups let you determine this physical location to meet either of these models. + +## Overview + +The Placement Groups service gives you a convenient way to set up groups of your compute instances, using Cloud Manager, API operations, or our CLI. Create a new placement group in a supported region and add new or existing compute instances from that region to your group. With the new group created, we physically move your compute instances into it, based on your desired model. + +## Availability + +The Placement Groups service is available in select regions. Currently, this includes: + +- Miami, FL (us-mia) + +- Chicago, IL (us-ord) + +{{< note >}} +Placement Groups is in limited availability. Throughout this phase, we expect to increase the number of supported regions. +{{< /note >}} + +## Affinity, enforcement, and compliance + +To distribute your compute instances in a placement group, we use the industry-recognized affinity standard. Pick from one of two types to serve as your "preferred container" type for your placement group: + +- **Affinity**. Your compute instances are physically close together, possibly on the same host. Set this as your preferred container if your application requirements value performance over availability. + +- **Anti-affinity**. Your compute instances are placed in separate fault domains, but they're still in the same region. Use this preferred container to better support a high-availability model. + +In addition to selecting the Affinity Type, you select how it's enforced when you add more Compute Instances to the placement group. + +- **Strict (Best practice)**. You can't add more compute instances to your placement group if your preferred container lacks capacity or is unavailable. For example, let's assume you've set **Anti-affinity** as your affinity type. If you try to add a compute instance that's on the same host, or there's no capacity outside that host in the region, you get an error and can't add the compute instance. This helps you keep your placement group compliant, because you can only pick compute instances that fit your desired model. + +- **Flexible**. You can add more compute instances to your placement group even if they're outside your affinity type's preferred container. However, if you add one and it violates your affinity type, the placement group becomes non-compliant. Once the necessary capacity is available in the data center, we physically move the compute instance for you to fit your affinity type's preferred container and make it compliant again. This can work for you if you know you need to add more compute instances to your group in the future. + +### Fix Non-compliance + +If a placement group becomes non-compliant, we're alerted and we'll bring it back into compliance as soon as possible. Non-compliance can only be fixed by Akamai staff. **_You can't fix it yourself_**. + +By design, a Strict placement group can't be made non-compliant when simply creating it or managing its Compute Instances. In rare cases, non-compliance can occur if we need to fail-over or migrate your Compute Instances for maintenance. Because of this, fixing non-compliance for Strict placement groups is prioritized over Flexible groups. + +## Create a placement group + +{{< tabs >}} +{{< tab "Cloud Manager" >}} +Here's how to create a new placement group and add existing compute instances to it. + +#### Before you begin + +Make sure you understand how placement groups work. Have a look at [Affinity, enforcement, and compliance](#affinity-enforcement-and-compliance). + +#### Creation process + +1. Navigate to the **Placement Groups** page in [Akamai Cloud Manager](http://cloud.linode.com) and click **Create Placement Groups**. The **Create Placement Group** form opens. + +1. Fill out the form with your desired settings: + + - **Label**. Give your placement group an easily recognizable name. + - **Region**. Select the [data center](#availability) that includes the compute instances you want to add. + - **Affinity Type**. Select the [affinity](#affinity-enforcement-and-compliance) that meets your model. + - **Affinity Type Enforcement**. Pick how you want to [enforce](#affinity-enforcement-and-compliance) compliance for your placement group, when adding compute instances to it in the future. + +{{< note >}} +- During the limited availability phase, only **Anti-affinity** is available for Affinity Type. +- Once you create your placement group, you *can't change its Affinity Type Enforcement*. +{{< /note >}} + +3. When you're ready, click **Create Placement Group**. A summary of your group is revealed. + +4. Select the **Linodes (0)** tab. + +1. Click **Assign Linode to Placement Group**. The Assign Linodes form opens. + +1. The **Linodes in \** drop-down is auto-populated with eligible compute instances in your selected Region. Pick one to add it and click **Assign Linode**. + +
+ +
+ +7. Review the **Linode limit for this placement group**, and repeat steps 5-6 to add more compute instances, as necessary. + +{{< note >}} +During the limited availability phase, you’re limited to a maximum of 5 compute instances in a placement group. +{{< /note >}} + +With all your compute instances added, we begin provisioning by moving them into the placement group to meet your selected Affinity Type. + +{{< /tab >}} +{{< tab "Linode API" >}} +Here, we combine API operations to create a new placement group and add existing compute instances to it. + +#### Before you begin + +Make sure you understand how placement groups work. Have a look at [Affinity, enforcement, and compliance](#affinity-enforcement-and-compliance). + +#### List regions + +Run this API curl request, making sure to properly paste in or reference your [API token](/docs/products/tools/api/guides/manage-api-tokens/). Store the `id` and `label` values for the region where your target compute instances live. +```command +curl -H "Authorization: Bearer $TOKEN" \ + https://api.linode.com/v4/regions +``` +{{< note >}} +During the limited availability phase, only specific [regions](#availability) support placement groups. +{{< /note >}} + +#### Identify the maximum number of compute instances + +Run this request, using the stored region `id`. Store the `maximum_linodes_per_pg` value. This represents the maximum number of compute instances you can add to a placement group for that region. +```command +curl -H "Authorization: Bearer $TOKEN" \ + https://api.linode.com/v4/regions/us-east +``` +{{< note >}} +During limited availability, you can have a maximum of 5 compute instances in a placement group. +{{< /note >}} + +#### List compute instances + +Run this request using the stored region `id` to filter the response. Identify the specific compute instances you want to include -- up to the `maximum_linodes_per_pg` value -- and store the `id` value for each. +```command +curl -H "Authorization: Bearer $TOKEN" + -H 'X-Filter: { "region": "us-east" }' + https://api.linode.com/v4/networking/ips +``` + +#### Create a new placement group + +Run this request to create a new placement group. Store the `id` value that's generated for it. + +- `label`. Give your placement group an easily recognizable name. +- `region`. Set this to the `label` you stored for your region. +- `affinity-type`. Set this to the [affinity](#affinity-enforcement-and-compliance) that meets your model. +- `is_strict`. Define how to [enforce](#affinity-enforcement-and-compliance) compliance for your placement group, when adding compute instances to it in the future. Set to `true`, strict enforcement is applied and `false` sets it to flexible. + +{{< note >}} +- During the limited availability phase, only anti-affinity (`anti-affinity:local`) is available for `affinity-type`. +- Once you create your placement group, you *can't change* its affinity type enforcement setting (`is_strict`). +{{< /note >}} + +```command +curl -H "Content-Type: application/json" \ + -H "Authorization: Bearer $TOKEN" \ + -X POST -d '{ + "label": "new-placement-group", + "region": "us-iad", + "affinity-type": "anti_affinity:local", + "is_strict": "true" + }' \ + https://api.linode.com/v4/placement/groups +``` + +#### Add compute instances to the group + +In this request, populate the `linodes` array with a comma-separated data center list of stored `id` values for the compute instances. In the URL, target the new placement group using its stored `id`. + +```command +curl -H "Content-Type: application/json" \ + -H "Authorization: Bearer $TOKEN" \ + -X POST -d '{ + "linodes": [ + 123, 456, 789 + ] + }' \ + https://api.linode.com/v4/placement/groups/12/assign +``` +With all your compute instances added, we begin provisioning by moving them into the placement group to meet your selected affinity type. + +#### More with the Placement Groups API + +There are several other operations in the [Linode API](https://techdocs.akamai.com/linode-api/reference/post-placement-group) that let you interact with placement groups. + +{{< /tab >}} +{{< /tabs >}} + +## Technical Specifications + +- Placement groups support dedicated and shared compute instance plans. Plan types can be mixed in a placement group. However, specialty hardware, such as GPUs aren't supported. + +- A compute instance can only exist in one placement group. + +- The Affinity Type and Region you select determine the maximum number of compute instances per placement group. This quantity is reflected in Cloud Manager when reviewing your placement group. With the API, the [GET /v4/regions/\{regionid\}](/docs/api/regions/#region-view) operation contains the `maximum_linodes_per_pg` element that displays this maximum. + +- Placement groups can be renamed or deleted. To delete a placement group, you need to remove all compute instances from it. + +- When you remove a compute instance from a placement group, it continues to function as-is, but the placement decisions are no longer guided by the group's Affinity Type. + +- Entry points to create a placement group are also available when creating a new compute instance or editing an existing one. \ No newline at end of file diff --git a/docs/products/compute/compute-instances/guides/placement-groups/pg-added-linode-v1.png b/docs/products/compute/compute-instances/guides/placement-groups/pg-added-linode-v1.png new file mode 100644 index 00000000000..a9820457e2a Binary files /dev/null and b/docs/products/compute/compute-instances/guides/placement-groups/pg-added-linode-v1.png differ diff --git a/docs/products/compute/compute-instances/guides/resize/index.md b/docs/products/compute/compute-instances/guides/resize/index.md index ff449008e8d..e71a7fa5857 100644 --- a/docs/products/compute/compute-instances/guides/resize/index.md +++ b/docs/products/compute/compute-instances/guides/resize/index.md @@ -10,115 +10,116 @@ image: resizing_a_linode.png aliases: ['/platform/disk-images/resizing-a-linode-classic-manager/','/resizing/','/platform/disk-images/resizing-a-linode/','/migrate-to-linode/disk-images/resizing-a-linode/','/guides/resizing-a-linode/'] --- -Changing a Compute Instances plan (and plan type) is made easy through the Cloud Manger. This includes upgrading to a larger plan or downgrading to a smaller plan. If you're expecting a temporary burst of traffic to your website, or if you're not using your plan's resource allotment as much as you thought, you can temporarily or permanently resize your instance. +You can easily change a Compute Instance's plan using Cloud Manger. Are you expecting a temporary burst of traffic to your website? Or, are you using your plan's resource allotment less than you thought? To accommodate, you can upgrade to a larger plan or downgrade to a smaller one, respectively. You can also change to a different plan type, such as switching from a Shared CPU plan to a Dedicated CPU plan. -## What to Expect +## Before you begin -- You can upgrade your Compute Instance to a larger plan, downgrade to a smaller plan, or even change to a different plan type (such as switching from a Shared CPU plan to a Dedicated CPU plan). +Consider these points before attempting a resize: -- While resizing a Compute Instance, it is migrated to a different physical host within the same data center. This new host may have slightly different hardware, though performance is consistent across our entire fleet. +- **Hardware changes, but performance is preserved**. While resizing a Compute Instance, Cloud Manager migrates it to a different physical host within the same data center. This new host may have slightly different hardware, but performance is consistent across our entire network. -- The disks are transferred to the new hardware at a typical rate of ~150 MB/sec. While you can use this rate to approximate any downtime, the actual transfer speeds may vary and downtime may be shorter or longer than expected. +- **There are two resize types**. You can choose from two resize types: a **warm resize** or a **cold resize**. The type you choose determines the amount of migration downtime during a resize. See [Warm Resize vs. Cold Resize](#warm-resize-vs-cold-resize) to determine which resize type is right for you. -- You can choose from two resize types: a **warm resize** or a **cold resize**. Which type of resize you choose will determine the amount of downtime your instance will experience when migrating from one host to another. See [Warm Resize vs. Cold Resize](#warm-resize-vs-cold-resize) to determine which resize type is right for you. +- **What's preserved**. All of your existing data and configuration settings are preserved during the resize, and your IP addresses remain the same. -- All of your existing data and configuration settings are preserved during the resize, and your IP addresses remain the same. +- **Placement groups aren't supported**. Resizing a compute instance removes it from a [placement group](/docs/products/compute-instances/guides/placement-groups/). The migration required for resizing moves the compute instance to a different physical host in a data center. This can break the Affinity Type setting that's required for a placement group. If your compute instance is in a placement group and you need to resize it, talk to your Akamai account team about other options. -## Warm Resize vs. Cold Resize +- **The transfer rate during a resize**. Your compute instance's disks are transferred to the new hardware at approximately 150 MB/sec. However, actual transfer speeds may vary. -There are two resize options to choose from when configuring your resize: **warm** and **cold**. The terms “warm” and “cold” refer to the [type of migration](/docs/products/compute/compute-instances/guides/compute-migrations/) that occurs during the resize process. Your instance must be powered on in order to attempt a warm migration. If your instance is powered off, you may proceed with a cold migration. +## Warm resize vs. cold resize -- **Warm resize:** A warm resize will make sure your Compute Instance remains up while migrating to a new host prior to being rebooted. During this process, your instance is synced across hosts while running, automatically powers off, goes through the resize job, and boots back up to complete the resize. If your instance fails to automatically power off, you will be notified of the failed job attempt. Should the warm resize fail, we recommend reattempting the resize process using the cold resize option. There is less downtime during a warm resize than a cold resize. +You have two resize options to choose from: **warm** and **cold**. Each refer to the [type of migration](/docs/products/compute/compute-instances/guides/compute-migrations/) that occurs during the resize process. -- **Cold resize:** A cold resize will shut down your Compute Instance, migrate it to a new host, and restore it to its state prior to the resize process (either booted or powered off). There is more downtime during a cold resize than a warm resize. +- **Warm resize**. Your compute instance remains up during the migration and it's rebooted once the migration completes. So, make sure your instance is powered on for this resize. If you see a warning message about an inability to power down your compute instance, try the resize again using the cold resize option. There is less downtime during a warm resize than a cold resize. -## Resizing a Compute Instance +- **Cold resize**. This shuts down your compute instance, migrates it to a new host, and restores it to its booted state prior to the resize process. -1. Log in to the [Cloud Manager](https://cloud.linode.com) and select the **Linodes** link within the left sidebar. +## Resize a compute instance -1. Within the list of Compute Instances, locate the instance you'd like to resize, click the corresponding **more options ellipsis** dropdown menu, and select **Resize**. This displays the **Resize Linode** panel. +1. Log in to the [Cloud Manager](https://cloud.linode.com) and select **Linodes**. + +2. In the list of compute instances, find the one you want to resize, click the corresponding **...**, and select **Resize**. The **Resize Linode** panel is displayed. ![The Resize Linode panel in the Cloud Manager](resize-linode-plan.jpg) -1. Select the desired plan. +3. Select the plan you want: - - **To select a larger plan**, review [Upgrading to a Larger Plan](#upgrading-to-a-larger-plan). + - **Select a larger plan**. Review [Upgrade to a Larger Plan](#upgrading-to-a-larger-plan). - - **To select a smaller plan**, you first need to resize the instance's disks. See [Downgrading to a Smaller Plan](#downgrading-to-a-smaller-plan). + - **Select a smaller plan**. First, resize the instance's disks. See [Downgrade to a smaller plan](#downgrading-to-a-smaller-plan). - - **To select a different plan type**, review [Switching to a Different Plan Type](#switching-to-a-different-plan-type). + - **Select a different plan type**. Review [Switch to a different plan type](#switching-to-a-different-plan-type). -1. Under **Choose Your Resize Type**, select **warm resize** or **cold resize** to determine how you would like your instance to resize. See [Warm Resize vs. Cold Resize](#warm-resize-vs-cold-resize) to help decide which option best suits your use case. +4. Under **Choose Your Resize Type**, select **warm resize** or **cold resize**. See [Warm resize vs. cold resize](#warm-resize-vs-cold-resize) to help decide which option best suits your need. -1. Check **Auto Resize Disk** if you'd like to automatically resize your Compute Instance's primary disk. This can only be selected if the following conditions are met: +5. Check **Auto Resize Disk** if you want to automatically resize your compute instance's primary disk. You can only select this if you meet these conditions: - The new plan provides more storage space than the current plan. - - There is only a single ext3 or ext4 disk (not a raw disk). A swap disk can also be present, but it will not be resized. - - ![The Auto Resize Disk checkbox](auto-resize-disk.png) -1. Enter the Compute Instance's label in the **Confirm** field and select the **Resize Linode** button to initiate the resize. + - There is only a single ext3 or ext4 disk (not a raw disk). A swap disk can also be present, but the process doesn't resize it. -1. If performing a warm resize, your instance will be powered on to complete the resize process. If performing a cold resize, your instance will return to its original power state (powered on or off). + ![The Auto Resize Disk checkbox](auto-resize-disk.png) -You are now able to utilize the resources of your new plan. +6. Enter the Compute Instance's label in the **Confirm** field and click **Resize Linode**. -## Upgrading to a Larger Plan +With a warm resize, Cloud Manager powers your instance on to complete the resize process. If performing a cold resize, Cloud Manager returns your instance to its original power state. -Upgrading to a plan with additional resources and capacity enables you to scale vertically. Larger plans can accommodate increased traffic and provide your application with the additional computing power it needs. Since larger plans come equipped with more resources, you may want to make adjustments to take advantage of these resources. +## Upgrade to a larger plan -- **Resize Disks:** When resizing a Compute Instance to a larger plan, you can (in most cases) opt to automatically resize the disks as well. If your instance does not meet the requirements for this functionality or if you decide not to do this automatically, you can manually resize the disks at any point. See [Resize a Linode's Disk](/docs/products/compute/compute-instances/guides/disks-and-storage/) +You can scale vertically when upgrading your compute instance to a plan with additional resources and capacity. Larger plans can accommodate increased traffic and give your application the additional computing power it needs. Since larger plans come equipped with more resources, you may want to make adjustments to take advantage of these resources. -- **Optimize Applications:** Many applications can be configured to enhance performance when additional resources become available. This configuration may include increasing the memory limit, enabling multiple threads, and increasing the maximum size of data, cache, logs, or other files. Review the documentation for your application and any software such as PHP, MySQL, Apache, or NGINX. +- **Resize Disks**. In most cases, you can opt to automatically resize the disks when resizing your compute instance. If your instance doesn't meet the requirements for this functionality, or if you decide not to do this automatically, you can manually resize the disks later. See [Resize a Linode's Disk](/docs/products/compute/compute-instances/guides/disks-and-storage/) -- **Enable Multi-Queue NICS:** When upgrading to a plan with two or more vCPU cores, make sure that the multi-queue NICs feature is enabled. In most cases, this feature is already enabled or will be enabled once the Compute Instance reboots during the resize process. However, older distributions may require additional steps. See [Configuring Multi-Queue NICS](/docs/products/compute/compute-instances/guides/multiqueue-nic/). +- **Optimize Applications**. You can enhance the performance for many applications if additional resources are available. You can do things like increase the memory limit, enable multiple threads, and increase the maximum size of data, cache, logs, or other files. Review the documentation for your application and any software such as PHP, MySQL, Apache, or NGINX. -## Downgrading to a Smaller Plan +- **Enable Multi-Queue NICS**. If you're upgrading to a plan with two or more vCPU cores, make sure the **multi-queue NICs** feature is enabled. Typically this is enabled by default. However, older distributions may require additional steps. See [Configuring Multi-Queue NICS](/docs/products/compute/compute-instances/guides/multiqueue-nic/). -Downgrading to a plan with less resources may be helpful when looking to reduce computing costs or after making your application use system resources more efficiently. When moving to a smaller plan, the combined size of the Compute Instance's disks must be equal to or less than the desired plan's storage allocation. +## Downgrade to a smaller plan -1. Determine the storage space that's included in the new desired plan. This information is listed on the [Pricing Page](https://www.linode.com/pricing/) (under the *Storage* column). +If you're looking to reduce computing costs, you can downgrade to a plan that uses fewer resources. This can also apply if you've tuned your application to use system resources more efficiently. -1. Determine the amount of disk space currently being used on your Compute Instance. To do this, log in to your instance via [SSH](/docs/guides/connect-to-server-over-ssh/) or [Lish](/docs/products/compute/compute-instances/guides/lish/) and run the following command: +1. Determine the amount of disk space you're using on your compute instance. Log in to your instance via [SSH](/docs/guides/connect-to-server-over-ssh/) or [Lish](/docs/products/compute/compute-instances/guides/lish/) and run the following command and review the *Used* column data: ```command df -h ``` - Specifically, review the *Used* column from the output of that command. - - - If you're using less space than your intended plan requires, you can move onto the next step without any further action. +2. Review Compute Instance plans to see if you can downsize. See the [Pricing Page](https://www.linode.com/pricing/). - - If you're using more space than your intended plan allows, you need to remove some files to free up some space before moving onto the next step. See the options for doing this in the [Download Files from Your Linode](/docs/guides/download-files-from-a-compute-instance/) guide. + {{< note >}} + If you're close to a downgraded size plan, you can try to free up space on your compute instance. See the options for doing this in the [Download Files from Your Linode](/docs/guides/download-files-from-a-compute-instance/) guide. + {{< /note >}} -1. Resize the Compute Instance's disks to fit within the storage space of the new plan. See [Resizing a Disk](/docs/products/compute/compute-instances/guides/disks-and-storage/). +3. Resize the compute instance's disks to fit within the new plan. See [Resize a Disk](/docs/products/compute/compute-instances/guides/disks-and-storage/). -## Switching to a Different Plan Type +## Switch to a different plan type -There are multiple Compute Instance options available, each with their own benefits and use cases. When resizing your instance, you are also able to switch to a different plan type that may better suit your workload. For help deciding on a plan type, review the [Choosing a Compute Instance Type and Plan](/docs/products/compute/compute-instances/plans/choosing-a-plan/) guide for advice and a comparison of each plan. +When resizing your instance, you can also switch to a different plan type that better suits your workload. Here are the Compute Instance plan types Akamai offers: -To switch your plan type, follow the instructions outlined within [Resizing a Linode](#resizing-a-linode). When choosing the plan, select the tab that corresponds with your desired plan type. +- **Dedicated CPU**. Optimized for CPU-intensive applications. This plan type is equipped with dedicated vCPU cores, suitable for almost any workload that requires consistently high CPU performance. Use cases include production (and high traffic) websites, e-commerce sites, machine learning, data processing, and much more. See [Dedicated CPU Compute Instances](https://www.linode.com/products/dedicated-cpu/). -See below for the different Compute Instance plan types available: +- **Shared CPU**. Balancing performance with value. This plan type is a solid foundation for many common use cases, including development, low-traffic websites, or any workload that doesn't require consistent 100% CPU usage. See [Shared CPU Compute Instances](https://www.linode.com/products/shared/). -- **Dedicated CPU:** Optimized for CPU-intenseive applications. This plan type is equipped with dedicated vCPU cores, suitable for almost any workload that requires consistently high CPU performance. Use cases include production (and high traffic) websites, e-commerce sites, machine learning, data processing, and much more. See [Dedicated CPU Compute Instances](https://www.linode.com/products/dedicated-cpu/). +- **Premium CPU**. Guaranteed hardware for CPU-intensive workloads. Built off of our Dedicated CPU offering, this plan comes equipped with the latest AMD EPYC™ CPUs to make sure your applications are running on the best available hardware with consistent high performance. Use cases include enterprise-grade production applications, video transcoding, and more. See [Premium CPU Compute Instances](https://www.linode.com/products/premium-cpu/). -- **Shared CPU:** Balancing performance with value. This plan type is a solid foundation for many common use cases, including development, low-traffic websites, or any workload that doesn't require consistent 100% CPU usage. See [Shared CPU Compute Instances](https://www.linode.com/products/shared/). - -- **Premium CPU:** Guaranteed hardware for CPU-intensive workloads. Built off of our Dedicated CPU offering, this plan comes equipped with the latest AMD EPYC™ CPUs to make sure your applications are running on the best available hardware with consistent high performance. Use cases include enterprise-grade production applications, video transcoding, and more. See [Premium CPU Compute Instances](https://www.linode.com/products/premium-cpu/). - -- **High Memory:** Optimized for memory-intensive applications. This plan type is also equipped with dedicated vCPU cores, though they contain more memory than other similarly priced plans. Use cases include large or high-traffic databases, caching servers, and more. See [High Memory Compute Instances](https://www.linode.com/products/high-memory/). +- **High Memory**. Optimized for memory-intensive applications. This plan type is also equipped with dedicated vCPU cores, though they contain more memory than other similarly priced plans. Use cases include large or high-traffic databases, caching servers, and more. See [High Memory Compute Instances](https://www.linode.com/products/high-memory/). - **GPU:** The only plan type that is equipped with high performance NVIDIA GPU cards. GPU plans are capable of processing large amounts of data in parallel, performing complex calculations much more efficiently. See [GPU Compute Instances](https://www.linode.com/products/gpu/). {{< note >}} -Pricing and plan options may vary by region. See our [Pricing](https://www.linode.com/pricing/) page for more information on pricing options and [How to Choose a Data Center](/docs/products/platform/get-started/guides/choose-a-data-center/#product-availability) for plan and product availability. +- See the [Choosing a Compute Instance Type and Plan](/docs/products/compute/compute-instances/plans/choosing-a-plan/) guide for advice and a comparison of each plan. + +- Pricing and plan options may vary by region. See our [Pricing](https://www.linode.com/pricing/) page for more information on pricing options and [How to Choose a Data Center](/docs/products/platform/get-started/guides/choose-a-data-center/#product-availability) for plan and product availability. {{< /note >}} +### How to switch + +Follow the instructions in [Resize a Linode](#resizing-a-linode). When choosing the plan, select the tab that corresponds with your desired plan type. + ## Troubleshooting -- **If a warm resize fails:** Should the warm resize process fail for any reason, you will receive a notification in Cloud Manager, as well as an email notification regarding the failed job. There are several reasons a warm resize may fail, including the inability to successfully reboot due to internal configuration settings. If this is the case, we recommend proceeding with a cold resize. +- **If a warm resize fails**. Cloud Manager generates a notification, and you get an email notification regarding the failed job. There are several reasons a warm resize may fail, including the inability to successfully reboot due to internal configuration settings. If this happens, try a cold resize. -- **If a cold resize fails:** Should the cold resize process fail to complete, we recommend reattempting the resize. If it continues to fail, reach out to our [Support](/docs/products/platform/get-started/guides/support/) department for assistance. +- **If a cold resize fails**. Retry it. If it continues to fail, reach out to our [Support](/docs/products/platform/get-started/guides/support/) department for assistance. For additional information on troubleshooting resizes or migrations, please see our [Compute Migrations](/docs/products/compute/compute-instances/guides/compute-migrations/) guide. diff --git a/docs/release-notes/api/v4.177.0.md b/docs/release-notes/api/v4.177.0.md new file mode 100644 index 00000000000..d232ca9dc88 --- /dev/null +++ b/docs/release-notes/api/v4.177.0.md @@ -0,0 +1,55 @@ +--- +title: API v4.177.0 +date: 2024-06-18 +version: 4.177.0 +--- + +### Added + +Several new operations in support of the [Placement Groups](/docs/products/compute/compute-instances/guides/placement-groups/) service launch (Limited Availability): + + - **List placement groups** ([GET /placement/groups)](https://techdocs.akamai.com/linode-api/reference/get-placement-groups)) + - **Get a placement group** ([GET /placement/groups/{id}](https://techdocs.akamai.com/linode-api/reference/get-placement-group)) + - **Create a placement group** ([POST /placement/groups/](https://techdocs.akamai.com/linode-api/reference/post-placement-group)) + - **Update a placement group** ([PUT /placement/groups/](https://techdocs.akamai.com/linode-api/reference/put-placement-group)) + - **Assign a placement group** ([POST /placement/groups/{id}/assign](https://techdocs.akamai.com/linode-api/reference/post-group-assign)) + - **Unassign a placement group** ([POST /placement/groups/{id}/unassign](https://techdocs.akamai.com/linode-api/reference/post-group-unassign)) + - **Delete a placement group** ([DELETE /placement/groups/{id}](https://techdocs.akamai.com/linode-api/reference/delete-placement-group)) + +### Changed + +- Updated operations in support of the Placement Groups service launch (Limited Availability): + + - **List Linodes** ([GET /linode/instances](https://techdocs.akamai.com/linode-api/reference/get-linode-instances)) - Added `placement_group` object to show the placement group the Linode belongs to. + - **Get a Linode** ([GET /linode/instances/{linodeId}](https://techdocs.akamai.com/linode-api/reference/get-linode-instance)) - Added `placement_group` object to show the placement group the Linode belongs to. + - **Create a Linode** ([POST /linode/instances](https://techdocs.akamai.com/linode-api/reference/post-linode-instance)) - Added `placement_group` parameter to include a new Linode in an existing placement group. + - **Clone a Linode** ([POST /linode/instances/{linodeId}/clone](https://techdocs.akamai.com/linode-api/reference/post-clone-linode-instance)) - Added `placement_group` parameter to include the cloned Linode in an existing placement group. + - **Initiate a DC Migration/Pending Host Migration** ([POST /linode/instances/migrate](https://techdocs.akamai.com/linode-api/reference/post-migrate-linode-instance)) - Added `placement_group` parameter to include the migrated Linode in an existing placement group. + - **Get your account** ([GET /account](https://techdocs.akamai.com/linode-api/reference/get-account)) - Includes `Placement Group` in the `capabilities` array for accounts with access to the service. + - **Get a region** ([GET /regions/{regionId}](https://techdocs.akamai.com/linode-api/reference/get-region)) - Included various parameters that describe placement group availability and limitations in a region. + +- Updated several Object Storage operations to support the new `regions` objects: + + - **Create an Object Storage bucket** ([POST /object-storage/buckets](https://techdocs.akamai.com/linode-api/reference/post-object-storage-bucket)) + - **List Object Storage buckets** ([GET /object-storage/buckets](https://techdocs.akamai.com/linode-api/reference/get-object-storage-buckets)) + - **List Object Storage buckets in a region** ([GET /object-storage/buckets/{regionId}](https://techdocs.akamai.com/linode-api/reference/get-object-storage-bucketin-cluster) -- Replaces the "List Object Storage buckets in a cluster" operation.) + - **Get an Object Storage bucket** ([GET /object-storage/buckets/{regionId}/{bucket}](https://techdocs.akamai.com/linode-api/reference/get-object-storage-bucket)) + - **Remove an Object Storage bucket** ([DELETE /object-storage/buckets/{regionId}/{bucket}](https://techdocs.akamai.com/linode-api/reference/delete-object-storage-bucket)) + - **Create a URL for an object** ([POST /object-storage/buckets/{regionId}/{bucket}/object-url](https://techdocs.akamai.com/linode-api/reference/post-object-storage-object-url)) + - **Modify access to an Object Storage bucket** ([POST /object-storage/buckets/{regionId}/{bucket}/access](https://techdocs.akamai.com/linode-api/reference/post-object-storage-bucket-access)) + - **Update access to an Object Storage bucket** ([PUT /object-storage/buckets/{regionId}/{bucket}/access](https://techdocs.akamai.com/linode-api/reference/put-storage-bucket-access)) + - **Get an Object Storage object ACL config** ([GET /object-storage/buckets/{regionId}/{bucket}/object-acl](https://techdocs.akamai.com/linode-api/reference/get-object-storage-bucket-acl)) + - **Update an object's ACL config** ([PUT /object-storage/buckets/{regionId}/{bucket}/object-acl](https://techdocs.akamai.com/linode-api/reference/put-object-storage-bucket-acl)) + - **List Object Storage bucket contents** ([GET /object-storage/buckets/{regionId}/{bucket}/object-list](https://techdocs.akamai.com/linode-api/reference/get-object-storage-bucket-content)) + - **Upload an Object Storage TLS/SSL certificate** ([POST /object-storage/buckets/{regionId}/{bucket}/ssl](https://techdocs.akamai.com/linode-api/reference/post-object-storage-ssl)) + - **Get an Object Storage TLS/SSL certificate** ([GET /object-storage/buckets/{regionId}/{bucket}/ssl](https://techdocs.akamai.com/linode-api/reference/get-object-storage-ssl)) + - **Delete an Object Storage TLS/SSL certificate** ([DELETE /object-storage/buckets/{regionId}/{bucket}/ssl](https://techdocs.akamai.com/linode-api/reference/delete-object-storage-ssl)) + - **Create an Object Storage key** ([POST /object-storage/keys](https://techdocs.akamai.com/linode-api/reference/post-object-storage-keys)) + - **List Object Storage keys** ([GET /object-storage/keys](https://techdocs.akamai.com/linode-api/reference/get-object-storage-keys)) + - **Get an Object Storage key** ([GET /object-storage/keys/{keyId}](https://techdocs.akamai.com/linode-api/reference/get-object-storage-key)) + - **Update an Object Storage key** ([PUT /object-storage/keys/{keyId}](https://techdocs.akamai.com/linode-api/reference/put-object-storage-key)) + +- Deprecated the following Object Storage-related operations. They are still available, but other operations should be used instead: + + - **List clusters** ([GET /object-storage/clusters](https://techdocs.akamai.com/linode-api/reference/get-object-storage-clusters)) + - **Get a cluster** ([GET /object-storage/clusters/{clusterId}](https://techdocs.akamai.com/linode-api/reference/get-object-storage-cluster)) \ No newline at end of file