Showing posts with label Virtual Machines. Show all posts
Showing posts with label Virtual Machines. Show all posts
Are Containers the future?
What are containers?
Containers can be compared to virtual machines but are very different. Containers contain groups of applications that can run directly on an underlying host operating system unlike virtual machines that require a hypervisor layer. This is greatly beneficial as you are able to achieve higher density, better elasticity, increased portability and advanced scalability. These advantages are achieved with less overhead management and administration.
The older way of achieving this same function was to have virtual machines running over a hypervisor which was running within a host operating system. Each of these layers require management and support and even the virtual machine had to run its own operating system. All of these operating systems require patching and other administration to operate. As you can see containers just contain the actual application and no other overheads are required.
How do containers work?
Containers are implemented using specific technology like Docker which was originally run within the Linux operating system. Nowadays containers can also be run on Windows. Docker containers are really the standard way of doing things now. If you require multiple containers, clusters or are looking to run containers in the cloud you need to look at Kubernetes which is the most popular container orchestration platform currently.
Kubernetes is an open-source container-orchestration system for automating deployment, scaling and management of containerized applications. It was originally designed by Google and is now maintained by the Cloud Native Computing Foundation.
Kubernetes is an open-source container-orchestration system for automating deployment, scaling and management of containerized applications. It was originally designed by Google and is now maintained by the Cloud Native Computing Foundation.
Can I use containers?
This question really depends on your specific workload and application. Most applications should be able to be ported into containers and then launched either onsite or in the cloud. One great thing about containers is that they can be run both onsite and in the cloud and are extremely portable between different operating systems and cloud platforms. With this flexibility its much easier to be able to move your containers anywhere you would like to run them. I would suggest further consultation with your developers and cloud architects to determine your use case and the best applicable solution for your use case.
Containers in the cloud
The easiest way to test and use containers in production is to launch them through your cloud platform. Each public cloud provider offers a widespread range of managed container solutions. Google Cloud Platform offers the original GKE Google Kubernetes Engine. This is currently the most advanced offering of managed Kubernetes in the cloud with Azure coming in second with the recently generally available AKS. Azure Kubernetes Service. Please read the below links in order to learn more about these platforms and containers.
Are containers the future?
Yes containers are the future of application technology in the cloud as well as on-premise. Containers are becoming more and more popular and learning and understanding some background in them whether you are a developer or operations engineer is really required. There are so many courses and further information out there and I suggest starting by looking at your cloud providers documentation to set you in the right direction.
Some great further information can be read here:
https://cloud.google.com/kubernetes-engine/
https://azure.microsoft.com/en-us/services/kubernetes-service/
https://www.docker.com/
https://kubernetes.io/
https://azure.microsoft.com/en-us/services/kubernetes-service/
https://www.docker.com/
https://kubernetes.io/
Cloud Based Compute Solutions
One of the most popular reasons for businesses moving to the cloud is for the use of compute power. This can be for migrating existing on premise workloads or transitioning to a cloud based virtualisation platform. Another reason with be the use of high performance computing. We will discuss some of the various compute options in this blog post.
Compute
Running compute power in the cloud is becoming the standard way to run virtual servers, application services as well as high performance computing. Using older approaches such as onsite data centres and servers with virtualisation has become costly and underused. Often the capacity is not fully used and there is also the cost of hardware maintenance.
By migrating your existing compute workloads to the cloud you can reduce cost, maintenance and increase your reliability and up time. You can migrate your virtual machines (VM's) directly into cloud platforms with minimum or no downtime. Once in the cloud you can then only focus on the management of the software layer and not hardware.
These days its become fairly standard to migrate existing on premises VM's into the cloud despite which hypervisor platform you are using i.e VMware or Hyper-V. You are also able to Physical 2 Virtual physial servers and migrate these to cloud. Please be careful to check your chosen cloud platforms operating system requirements prior to starting any migrations.
HPC High Performance Computing
Another very interesting use of cloud computing is for high performance computing (HPC) using large scale batch compute tasks to run huge loads like rendering. This can be much easier and cheaper than trying to build and run this in an on premise data centre. In the cloud you only pay for what you use and not the spare unused capacity. In HPC you may not be constantly running these workloads so you will not pay for unused compute time.
IaaS and PaaS
You are able to run compute functions in Infrastructure as a Service (IaaS) whereby you manage and look after your own infrasructue or VM's or via Platform as a Service (PaaS) were you can directly spin up specific functions like web apps that run in the cloud. IaaS may be more suited to a business looking to import existing infrastructure into the cloud and PaaS may be better suited to developers not interested in maintaining any infrastructure.
Containers
Containers are pretty much the future of running applications in the cloud (or even on premises) and with using solutions like Docker and Kubernetes the process of deploying containers has become much easier. In the cloud you can use the relevant cloud platforms Kubernetes engines to spin up containers in seconds and to mange them going forward. Google Cloud's GKE is really leading in this space with Microsoft's AKS which has just become GA (Generally Available) quickly catching up. I will be writing a blog post post about Containers in the near future as this is becoming a really hot topic in cloud computing.
Serverless Functions
Serverless and functions are used by developers to write and run code immediately and not have to deal with any servers or infrastructure at all. Code can be directly run and actioned without any need to worry about capacity planning or server management. Of course there are servers required but these are all managed by the cloud platforrms.
Serverless Functions
Serverless and functions are used by developers to write and run code immediately and not have to deal with any servers or infrastructure at all. Code can be directly run and actioned without any need to worry about capacity planning or server management. Of course there are servers required but these are all managed by the cloud platforrms.
https://cloud.google.com/products/compute/
https://azure.microsoft.com/en-us/product-categories/compute/
Implementing Cloud Infrastructure
To break it down this is very comparable to on premises infrastructure as when looking to physical storage, physical servers, virtualisation, virtual networks and virtual machines. The cloud reduces the need have the physical infrastructure in place. You are able to utilise this on a pay per use model in any of the public cloud providers for example Google Cloud Platform or Microsoft Azure. You are charged for what you use which is great!
Virtual Networks
After activating your cloud subscription you can begin setting up your virtual network. This has different names depending on what provider you are using i.e in Microsoft Azure its called Virtual Networks and in Google Cloud Platform its called Virtual Private Cloud Networks (VPC's) Basically these are similar ways to perform network segmentation in the cloud based on virtualised networks. Subnets are used to segment these virtual networks or VPC's. You are also able to integrate load balancers and firewalls:
Within these virtual networks you can isolate specific services, i.e virtual machines, you can implement load balancers as well as connect networks from different regions togeather. You are also able to implement security with firewall's across these virtual networks both internally and externally. Another feature of virtual networks is the ability to connect them with your existing on premises networks. There are various methods available in order to achieve this as in a direct Interconnect (GCP) or Express Route (Azure) link from your site to the applicable cloud provider. Another way do to this is be using secure encrypted VPN tunnels:
Cloud Storage
Cloud Storage is absolutely critical as this is where all of your resources will be stored in the cloud. I have previously written about cloud storage if you would like to read further:
In the context of this article we will be referencing more towards storage of infrastructure like virtual machine files, virtual machine disks and general file storage. These will be the locations where your compute workloads will be stored when created. There are various different types of storage but for virtual machines you will look at options like HDD or SSD depending on workload. Google GCP has persistent disks and Azure has managed disks for VM's. http://www.ruckcloud.ml/2018/04/lets-talk-about-managed-disks.html
Compute
The compute layer is all about the computing resources that you will be utilising. This is based on virtual machines in one form or the other. You can spin up traditional VM's one at a time with a large selection of different operating systems from Windows to Linux. These are called IaaS (Infrastructure as a Service) VM's. You can also leverage batch operation with automating a large number VM creation to achieve a large processing job for example. These VM's can automatically scale up and down based on load and you are only charged when they are in use. With IaaS you have direct control and management of your VM's.
You are also able to make use of virtual machines in PaaS (Platform as a Service) where you can immediately spin up app's for computing needs without the need of managing IaaS VM's. This is very handy for developers that are not too concerned with managing VM's.
In this article I have touched on the core base infrastructure required with cloud computing. These areas all go into much more depth but sometimes its nice to get a simple overview of what they are and how they work. This is really essential to understand when first looking into the cloud to either build new services or migrate your existing infrastructure.
Further information on cloud infrastructure is available at:
Lets talk about managed disks
Managed disks are Azure managed virtual machine disks that are easily added during virtual machine (VM) builds. When activating the managed disk its added to your VM in replacement of the traditional storage account based unmanaged disk. Originally this was the only way of doing this as all VM disks had to be placed into storage accounts. Adding a managed disk though VM creation is a very easy process and literally takes one click:
There are many advantages for using manged disks opposed to traditional unmanaged disk storage which are mainly related to less overhead management, less resource sprawl, secured disk storage, better high availability and reliability on virtual machine disk storage.
Simplified Management - You can specify the type of disk and size needed and Azure will automatically create and manage the disks for you.
Scalable virtual machine deployments - Create thousands of managed disks within minutes. Create up to 1000 virtual machines in scale sets in a single large cluster.
More Secure - Using Azure RBAC (Role Based Access Control) you are able to create granular role based access control on your managed disks.
Highly durable and available - Your data is replicated simultaneously to three different replicas. If one replica fails there are two others to take over.
The below is a great comparison between unmanaged and managed disks:
There are also various further advantages of using managed disks. Namely multiple storage options like SSD premium managed disks for critical performance intensive workloads, and HDD for standard managed disk non-critical workloads. Easy migration from standard to premium managed disks as well as your existing ARM (Azure Resource Manager) virtual machines into managed disks. Point in time backup snapshot of your managed disk to create new managed disks later. Simple custom image management and encryption with bringing your own keys is available.
Managed disks are now the best way to use virtual machine disks in Azure. It's actually much easier to roll out and less admin than unmanaged disks as well as more reliable.
Managed disks are now the best way to use virtual machine disks in Azure. It's actually much easier to roll out and less admin than unmanaged disks as well as more reliable.
Please read the following for additional information:
Using Azure Security Center for monitoring
You are able to apply policies and also locate and fix vulnerabilities before they can be exploited. What is also great is that you are able to leverage advanced analytics to detect and mitigate attacks on your infrastructure using the Advanced Threat Protection module.
In this article I will go about explaining the basics of this service, from locating where to find it to some basic overviews of the monitoring dashboard and some of the remediation features. As with all my articles they can be read by the first time Azure user all the way up to a seasoned pro who may be interested in learning about a new product.
The Azure Security Centre is simply launched from within the Azure portal:
Once you have opened the portal, it will display your monitoring dashboard with alerts:
This dashboard will contain your security related overview, prevention and detection. Please note that you will require an additional 60 day trial to view the Advanced Threat Detection. the Advanced Threat Detection is an advanced feature that can be used to automatically locate and resolve security issues based on the Azure Security Centre intelligence.
Recommendations
When monitoring the dashboard you can scroll through and check the recommendations that can be implemented to better secure your current workload, these are arranged into a high and medium severity. When opening these they will provide instructions on how to resolve and implement better security practises onto your cloud or on-premise workloads.
As per the the above recommendation I have located that I am not using a Network Security Group (NSG) on a specific virtual network. I can then click through the blades in order to find more information on this specific issue and resolve it directly from within the portal. As per the below I can directly enable the required NSG through the next portal steps:
Prevention
Under the prevention tab you will see additional alerts generated based on your infrastructure. These tabs will contain compute, networking, storage & data and applications.
In my example I have a few alerts across compute and networking. When clicking on the compute tab I am given the following recommendations with regards to my virtual machines:
From within this tab I can continue through to obtain further information as in this case I have not installed the endpoint protection on the virtual machine (this is used to scan for malware threats) as well as having missing disk encryption on the virtual machine disks. Within the following windows you will receive further information and directions for resolving these issues. This allows you to become proactive with regards to security issues.
Within networking, storage and data similar issues are reported with further information on the threats and directions on how to resolve them. This is incredibly useful and provides a great overview of your Azure infrastructure security and gives great direction on resolving any issues that may have been located.
One other point that I haven't mentioned is that you can also install the Azure Security Centre monitoring agent on on-premises machines which create a fully hybrid cloud security monitoring overview. Its also great as you can have all security information for cloud and on-premises in one place (dashboard) for monitoring and reporting. A Log Analytics work space is required to on-board non-Azure computers to Security Centre:
There are a lot more functions that can be enabled within Azure Security Centre and I have only touched on the basics in this article. Please feel free to look further into Advanced Threat Detection which contains great threat intelligence and security alerting functions.
Further information can be found here: https://azure.microsoft.com/en-gb/services/security-center/ and documentation here: https://azure.microsoft.com/en-us/documentation/services/security-center/
Using Azure Site Recovery with Managed Disks
Today I will be elaborating on that article slightly to explain a new feature that was announced last week around being able to protect Azure VM's using managed disks.
What are managed disks?
Managed disks are basically VM level disks that are managed and controlled by Azure. What this means is that when you are creating a new VM you are given an option of using an existing storage account and creating a normal disk in this location or the option of selecting a managed disk. A managed disk simplifies overall storage management and is also more reliable as its managed by Azure and will have better high availability during planned or unplanned maintenance. This can really help with making your life easier!
What is Azure Site Recovery?
As mentioned in the previous article Azure Site Recovery is used to be able to provide a business continuity disaster recovery (BC/DR) service for your IaaS VM's in Azure or on premises. ASR can also be used to migrate your on premises VM's into Azure. For further information on configuring this to protect an indivudual VM's please view the full article here: http://www.ruckcloud.ml/2018/02/using-azure-site-recovery-to-replicate.html
The new feature announced is implemented within the disaster recovery (preview) section and relates to your selections for setting up protection. You now have the option to select managed disks for replication. What this means is that you can select the manage disks that you would like to migrate to the secondary region, thus creating a fail-over copy. This also means that you will not need to select a storage account to migrate unless you still have VM's that may be located in them. Below is an image from Microsoft depicting this:
As you can see from this image, you now have the following options:
Source Managed Disk - Your original primary location VM managed disk
Replica Managed Disk - Your new replica managed disk location for protection
Replica Managed Disk Type - The type of managed disk that was initially selected
So in order to sum up this service, the advantage that this gives us is that any VM's with managed disks can easily be replicated to a secondary region through the Azure Site Recovery (preview) service without the need of managing multiple storage accounts within the target location in order to manage all of your replicated virtual machines.
Please read the official Microsoft blog post on the subject for further detailed information:
Using Azure Site Recovery to replicate a VM
Today I will be writing about Microsoft Azure's Azure Site Recovery (ASR) service. This is really an incredible service that makes running your own DR replicated "secondary site" easy and cost effective.
The Microsoft Azure ASR service is a cloud based business continuity and disaster recovery (BC/DR) service. It can be used for a whole bunch of different scenarios, as in copying on premises virtual machines (VM's) into Azure within a hybrid cloud model which can then be used in a full scale DR replication situation, permanently migrating on premises Hyper-V and VMware VM's into Azure and also for protecting current Azure VM's by replicating them to other regions. These options could also be used together depending on your architecture and individual requirements. Please view the official Microsoft Documentation for in depth required information.
In today's blog post I will be writing about the option of simply protecting your current VM's running in Azure as this is a good way to initially start using and learning the service. Please note that there are also various options for setting this up for a large number of VM's, but the below guide is just for a single VM running within Azure. For any further information the Azure documentation linked at the bottom of this article a great place to start!
As of writing this feature is still listed as under preview within the Azure portal.
1. Login in to the Azure portal:
2. Select an existing VM and then click on the "Disaster recovery (preview)" tab:
3. Next you will need to specify the region that you would like to replicate to, as well as some further information, as in your existing resource group, availability sets and virtual network. Some of these settings will auto populate depending on the location of the current region of the selected VM, as in this case "West Europe":
4. The next information required is related to storage, you will need to check or adjust the initial storage location (if not managed disks which aren't being referenced in this article - this particular VM is using an existing storage location), as well as setup a new or existing recovery services vault which will be used for the replication. A recovery services vault is a storage "backup" location in which your VM will be copied and stored. You can also select a new or existing resource group as well as replication policy. If you leave these as defaults new resources will be automatically created for you:
5. Once you have completed the above steps you will see a graphic displaying the available replication regions:
6. if all looks good click "Enable replication" and that's it, replication will begin! :)
Once completed you can check the replication status within the same "Disaster Recovery (preview tab)" above.
You are also able to delete the replication and adjust other settings if required.
Source: https://docs.microsoft.com/en-us/azure/site-recovery/azure-to-azure-quickstart
Configuring backups on VM creation in Azure
In this blog post I will be detailing how to enable virtual machine (VM) level backups during VM creation in Azure. This is a great function as it enables you to automatically create backups of your VM's directly within the Azure portal while creating a new VM.
You can also use the same basic steps below in order to create backups on your existing VM's by selecting the VM and Backup tab on your existing VM's within the Azure portal.
1. Log into the Azure portal and select New - Windows Server 2016 VM (or any other version that you are requiring). Select your relevant basic settings and continue:
2. Select the size of the VM that you would like to create and continue:
3. Under the backup tab, select "Enabled". You can now specify your new or existing "recovery services" or backup vault. This will be a storage location for your VM level backups. You will also be able to select an existing or new resource group:
4. The next step is to configure the backup policy itself, this can be done by selecting "Backup policy" and creating your policy based on your individual or compliance needs.
5. After this has been done you can complete the new VM wizard and your new VM will be provisioned in Azure. Your VM backups will automatically start running based on your policy.
Please note: The steps 3 & 4 can also be completed on an existing VM in order to create an automatic backup procedure. A recovery services vault will also be required for storage.
Once you have completed these steps your backups will be handled by Azure and recovery points will become available under the backup and restore tab of the individual VM's. You can use this to perform point in time restores of your VM's in any backup restore scenarios.
I hope that you have found this article interesting and can enable this on your next VM build!
Source: Please read the official Microsoft documentation for further information:
Why using availability sets is critical in Azure
Yesterday we learnt that using availability sets are more than just a recommended best practise in Microsoft Azure. As Microsoft had scheduled maintenance updates for the Spectre/Meltdown vulnerability for January 10th these were suddenly scrambled into action due to the public announcement of the issue, and updates automatically completed from January 3rd into January 4th without any advance warning.
These updates were obviously critically required and absolutely the right decision from Microsoft but it did also create issues for customers that had production servers rebooted during business hours. Of course these issues did not impact customers that were already utilising availability sets within their infrastructure for high availability.
Availability sets consist of update domains that two or more virtual machines (VM's) are connected to when originally provisioned. These update domains are updated and rebooted at different times thus preventing downtime across VM's that have been provisioned in them creating a high availability redundancy across your applications.
This is useful in the three scenarios - unplanned hardware maintenance events, an unexpected downtime or a planned maintenance event. Each VM in an availability set is placed in an update domain (UD) and a fault domain (FD). A fault domain is used for shared power and network at the rack level. Please read about this more in further detail in the official documentation linked at the bottom of this article.
Microsoft also recommends utilising managed disks when provisioning new VM's in availability sets (or in general) as this creates better availability of disks by isolating them using different storage clusters, as well as creating less overhead management of storage accounts associated to various VM's that you are provisioning.
It is also a good idea to add VM's of different application tiers into their own availability sets as this creates better redundancy for your applications. For example you can place front end web servers in one availability set and back end database servers into a separate availability set. This creates a situation that you will have one server from each tier online at the same time preventing downtime to your application.
To sum it up availability sets need to be thought about and addressed in planning of your architecture and should really be implemented for any business critical VM's or applications in order to prevent any downtime as some experienced yesterday.
Subscribe to:
Posts (Atom)
