Fell with AWS? Stop by without question, documents later, now not before

    While I was driving to work and listening to Dolphin's new album, someone was blocking the IP addresses of Amazon and Google with entire subnets. Roskomnadzor called inaccurate information about blocking sites that are not related to Telegram, but renting IP addresses on the same services as the messenger, and created a hotline to prevent the spread of such messages.

    Therefore, I don’t even know why we had to help several services during the past day. Someone was hurt quite a bit, but someone had to migrate.

    In short, we can quickly migrate from AWS. We have a compatible API. We can also migrate customers from Google. And in the coming weeks, we are ready to do the migration for free and give a month for tests in our cloud without a contract and without a guarantee letter, simply on the company’s card. If you don’t like it, you don’t have to pay anything.

    Below is howto for different types of VM unloading from Amazon.

    We are seeing a surge in interest in Russian clouds right now. We understand that those who encounter locks can either wait or urgently migrate their services to an accessible public cloud.

    Migration requires access, agreements with support, conclusion of an agreement.

    We are ready to skip these formalities and give access by letter to MBerezin@croc.ru.

    Compatibility


    The CROC cloud is developing in many ways according to the AWS scenario: we ourselves are developing our virtualization platform based on KVM. Naturally, in the process we adopt the experience of our Western colleagues, therefore we can also boast compatibility with AWS, which we greatly respect.

    Thesis:

    • Two access zones based on our own network of data centers,
    • Equally fast network for all VMs regardless of their type,
    • A fast network between the VM and the physical infrastructure located in the data center,
    • High-performance drives with fixed IOPS (analog io1 in AWS),
    • Full service import / export of virtual disks,
    • Free user traffic in S3.

    Your customized automation will work in our cloud without any serious problems. We have implemented the basic functionality of the three services Elastic Compute Cloud (EC2), Simple Storage Service (S3), CloudWatch.

    Migration options


    1. The standard procedure for import / export of VMs is described in the documentation .
    However, there is an important limitation: export is only possible for machines that were previously imported into AWS. Otherwise, we get an error:

    $ aws ec2 create-instance-export-task —instance-id i-XXXXXXXXXXXXXXXX —target-environment vmware —export-to-s3-task DiskImageFormat=vmdk,ContainerFormat=ova,S3Bucket=my-export-bucket
    An error occurred (NotExportable) when calling the CreateInstanceExportTask operation: Only imported instances can be exported.

    If you succeeded in exporting the instance, then you need to download it from AWS S3.

    Next, download the downloaded image into CROC S3. To do this, download the settings file for accessing the CROC Cloud API, configure s3cmd to work with our S3, and load the disk image.

    2. If you cannot export the instance (the machines were created from AWS templates), you can bypass the restriction as follows: the VM disk must be dumped into an image file, which will need to be loaded into our S3.

    a) Create a temporary EBS volume slightly larger than the original
    b) Create a file system on the temporary volume and mount it:

    # mkfs.xfs /dev/xvdf1
    # mkdir /tmp/export
    # mount /dev/xvdf1 /tmp/export

    c) Install qemu-img
    d) Stop the entire butt and services, remove the disk image:

    # qemu-img -O qcow2 -o compat=0.10 /dev/xvda /tmp/export/web1-xvda.qcow2

    e) Download the file /tmp/export/web1-xvda.qcow2 to CROC S3, create a template from it and start the instance from it in the same way as in the first version.
    f) unmount and delete the temporarily created EBS

    3 volume . Similarly for other OSs, in Windows it is possible, for example, to create VHD / VHDX through the disk control panel.

    4. You can consider the option of backup and restore it to another machine.

    5. If transferring files (for example, content) is sufficient, rsync can be used on Linux and robocopy on Windows.

    6. If downtime or large volumes are quite expensive, you can work with OS and file system replication through Double Take / Carbonite.

    In general, there are a lot of options, it all depends on how the particular infrastructure is arranged. In all of these options, our support is well understood, and we have experience of such migrations. Plus, our certified AWS specialists, so we can definitely help.

    Have questions - contact in the comments or write: MBerezin@croc.ru

    Also popular now: