Auto-scale persistent storage - openshift

My application runs on an embedded database that writes to file system storage instead of a standard database. I want to know how to set my OpenShift app to be able to have persistent storage that automatically grows.
Currently, my application database writes into a mount path in the file system (in standard Linux environment), e.g. /mnt/db If I moved it to Openshift how can I be able to have such persistent storage that scales as the data grows?
From the Openshift pricing page: https://www.openshift.com/products/online/
It shows storage from 2GB to 150GB, does it mean that this is the hard limit? How about my application data hits 1TB above? It would not work with current Red-hat hosted version of Openshift?

Related

What is difference between snapshot, image and persistent disk on Google Compute Engine?

I have a compute engine instance on google cloud which is running fine. user base is increasing and I wish to upgrade to a bigger compute engine in terms of cpu and memory.
What is the most easy way to do such migration?
What is the snapshot, image, persistent disk features in google compute engine? Are they anyway useful to my task?
I figured it out. Lennert answer is good. I will add few more things to complete it. You can always stop a VM, edit the CPU/memory and restart the VM. But this action may change the external IP address and cause lot of issues. You can handle it but it may cause further downtime. You may have to update the new IP address at DNS and inside the code. One way to avoid this hassle is that you should Reserve a static IP adreess [in console, go to NETWORKING > EXTERNAL IP ADDRESS > RESERVE A STATIC IP ADDRESS]. If you do this, your ip address will not change once you restart the VM.
Image is aka Operating System. While creating a VM, you are asked to choose a boot disk, disk which is used to boot your VM from. You can select from pre-defined images.
Snapshot is the copy of the disk. If it is a boot disk, it contains the operating system image too. We can create a snapshot of an existing disk and use it as the boot disk while creating new VM.
Persistent Disk is the disk that can persists even if you delete the VM [provided you have deselect the option of deleting it while deleting the VM]. We can delete VM and use a persistent disk to create new ones. We can simply pay for persistent disk only, without having any VM.
The easiest way is to stop the machine, change the machine type from the console and start the machine again. No need to create backups (snapshots), new VM's, etc.

Amazon EC2 backup options and differences

I have an EC2 Instance running Windows Server 2012. My server is running a MySQL database, a wordpress website, and a Web Service, all in IIS. I installed these manually and configured them myself if that's important.
I looked into methods for backing up, and came across EBS Snapshots (Elastic Block Store > Snapshots > Create Snapshot), and Images (Instances > Actions > Image > Create Image). From my understanding, an EBS Snapshot is a snapshot (backup) of any attached EBS volumes (in my case the root drive C). An Image is an image of the entire instance. Am I correct so far in my descriptions of the two methods?
I want to have a backup of my server as described above (database, wordpress, web service, iis settings). Would am EBS Snapshot suffice for this? i.e, if my instance or ebs volume fails one day, by recreating an instance and attaching the EBS snapshot to the new instance, will my server be configured the same as the failed instance (database, wordpress, web service, iis settings, etc)?
I am assuming an Image restore to a new instance will mean absolutely everything will be restored as on the initial instance correct?
So with all that said, would an EBS snapshot be enough as a backup solution?
An EBS Snapshot is a crash consistent backup of your volume. By crash consistent it means that it is as good as if your machine crashed (for example, you unplug your computer). It means that open files that have pending changes in buffers might not had been persisted to disk.
So it is not an application consistent backup such as those that can be done with applications that support VSS snapshots, but probably it will be good enough for basic disaster recovery.
Here you will find more info about crash consistent and application consistent backups.
Another important caveat is that for Windows instances, you want to create your AMIs by using Instances > Actions > Image > Create Image. If you try to create a Windows AMI from a volume, it will default to Linux and you won't be able to use them as an AMI to reinstantiate your Windows Server.

Google Compute Instance 100% CPU Utilisation

I am running n1-standard-1 (1 vCPU, 3.75 GB memory) Compute Instance , In my android app around 80 users are online write now and cpu Utilisation of instance is 99% and my app became less responsive. Kindly suggest me the workaround and If i need to upgrade , can I do that with same instance or new instance needs to be created.
Since your app is running already and users are connecting to it, you don't want to do the following process:
shut down the VM instance, keeping the boot disk and other disks
boot a more powerful instance, using the boot disk from step (1)
attach and mount any additional disks, if applicable
Instead, you might want to do the following:
create an additional VM instance with similar software/configuration
create a load balancer and add both the original and new VM to it as a backend
change your DNS name to point to the load balancer IP instead of the original VM instance
Now, your users will be randomly sent to a VM that's least-loaded to see the application, and you can add more VMs if your traffic increases.
You did not describe your application in detail, so it's unclear if each VM has local state (e.g., runs a database) or there's a database running externally. You will still need to figure out how to manage the stateful systems such as database or user-uploaded data from all the VM instances, which is hard to advise on given the little information in your quest.

How to set boot disk for SSD in google compute engine?

I try to create a click to deploy website site and select SSD as my pesistent disk
however after creation I can see that google created a normal 10GB disk as my boot and not the SSD one, how do I change that?
even though there is two pesistent disk now
Which click-to-deploy machine have you created ? For example, using a LAMP stack, you sill the option to create a Data disk as SSD. This is not the same disk as your boot disk, it will be an additional one.
You may have to create the GCE instance from scratch using the Web GUI. In Compute engine > Disks, you have the option of creating SSD disks that can be used as boot when creating a new machine. After that is done, you can install your web server.

Google Compute Engine adding disk and SSL support

I am new to GCE. I was able to create new instance using gcutil tool and GCE console. There are few questions unclear to me and need help:
1) Does GCE provides persistent disk when a new instance is created? I think its 10GB by default, not sure though. What is the right way to stop the instance without loosing data saved on it and what will be the charge (US zone) if say I need 20GB of disk space for that?
2) If I need SSL to enable HTTPS, is there any extra step I should do? I think I will need to add firewall as per the gcutil addfirewall command and create certificate (or install it from third part) ?
1) Persistent disk is definitely the way to go if you want a root drive on which data retention is independent of the life cycle of any virtual machine. When you create a Compute Engine instance via the Google Cloud Console, the “Boot Source” pull-down menu presents the following options for your boot device:
New persistent disk from image
New persistent disk from snapshot
Existing persistent disk
Scratch disk from image (not recommended)
The default option is the first one ("New persistent disk from image"), which creates a new 10 GB PD, named after your instance name with a 'boot-' prefix. You could also separately create a persistent disk and then select the "Existing persistent disk" option (along with the name of your existing disk) to use an existing PD as a boot device. In that case, your PD needs to have been pre-loaded with an image.
Re: your question about cost of a 20 GB PD, here are the PD pricing details.
Read more about Compute Engine persistent disks.
2) You can serve SSL/HTTPS traffic from a GCE instance. As you noted, you'll need to configure a firewall to allow your incoming SSL traffic (typically port 443) and you'll need to configure https service on your web server and install your desired certificate(s).
Read more about Compute Engine networking and firewalls.
As alternative approach i would suggest deploying VMs using Bitnami. There are many stacks you can choose from. This will save you time when deploying the VM. I would suggest you go with the SSD disks, as the pricing is close between magnetic disks and SSDs, but the performance boost is huge.
As for serving the content over SSL, you need to figure out how will the requests be processed. You can use NGINX or Apache servers. In this case you would need to configure the virtual hosts for default ports - 80 for non-encrypted and 443 for SSL traffic.
The easiest way to serve SSL traffic from your VM is generate SSL certificates using the Letsencrypt service.