Disaster recovery(DR) must be reliable, speedy and economical. These are the basic requirements for all businesses, and small to medium-sized enterprises (SMEs) are no exception. But, for smaller firms, cost considerations will be at or near the top of the IT managers list.

Organisations often view disaster recovery as little more than insurance, or as IDC analyst Phil Goodwin puts it, an expense that is likely to have little payback.

Large firms in highly regulated markets such as financial services invest heavily in disaster recovery and business continuity, not least because they are mandated to do so.

RBS, for example, was fined 56m for an IT failure in 2012.

Smaller firms might not have the budget for DR, however. Or they might choose not to pay for it, hoping they can ride out any incident with backups and hard work. This is short-sighted.

The Uptime Institutes 2018 Global Data Center Surveyfound that 31% of businesses experienced downtime that caused severe damage, but that 80% of incidents could have been prevented.

Operating disaster recovery on a pay-as-you-go model, combined with faster data transfers over the public internet, is transforming DR options for SMEs

Disaster recovery is becoming cheaper, simpler and more effective, through the growth of cloud-based services.

Firms no longer need to invest in dedicated or duplicate hardware, remote datacentres and the skilled staff to maintain them. Cloud or hybrid cloud technologies allow smaller companies to outsource much of the technical side of DR provision and to move to an on-demand model.

Operating disaster recovery on a pay-as-you-go model, combined with faster data transfers over the public internet, is transforming DR options for SMEs.

For smaller firms, conventional backup and disaster recovery has long meant saving data to tape or other removable media and storing it off-site. In case of a disaster the firm would need to source new hardware and restore data and applications.

Larger or better-resourced businesses, or those depending heavily on their data, will have invested in automatic off-site data replication and even standby servers. Others contracted with specialist suppliers to manage DR.

In the past, DR meant having a redundant location that was either always-on, a hot DR facility, or the use of shared resources that would be configured and set up when needed, says Roy Illsley, a distinguished analyst at Ovum who covers infrastructure solutions. These solutions are typically expensive or bring long recovery times.

Some businesses have moved to ad-hoc cloud backup solutions, including consumer-grade online storage. But this is still labour-intensive.

Small and medium-sized enterprises often deem disaster recovery too expensive or peripheral to core operations to fully invest in, warns Mark Wass, a director at business continuity supplier Sungard.

They often settle for a DIY, cloud-based platform approach, which they believe to be cheaper, and then assign responsibility for managing it to the office manager, he says.

Although this avoids reliance on on-site backups, it is still a manual process. And, Wass says, assuming staff can rely on cloud-based storage and access to a personal device to work on is risky.

Fortunately, the market for online disaster recovery is growing, and so is the choice of suppliers. Companies such as Veeam, Rubrik, Commvault, Cohesity and Nutanix provide options for businesses that need an off-the-shelf solution.

Cloud-based DR is available either directly from suppliers, or through managed service providers and IT integrators.

OGL Computer is a managed service provider with 1,200 UK SME customers. It offers a choice of cloud recovery and cloud-based data replication, as well as dedicated recovery options for VMware and Hyper-V. Recovery allows firms to restore their key applications within 24 hours cloud-based replication provides recovery within seconds.

But, as OGLs enterprise solutions architect, Steve Bennett, says, there are also customers who need, or prefer, an on-premise solution.

The availability of cloud services is an obvious way backup is becoming easier for SMEs, says Bryan Betts, analyst at Freeform Dynamics. But if they cant or dont want to use cloud, theres also the appliance option, either physical or virtual.

The availability of cloud services is an obvious way backup is becoming easier for SMEs. But if they cant or dont want to use cloud, theres also the appliance option, either physical or virtual Bryan Betts, Freeform Dynamics

Add in the availability of flash storage and modern software that provides user self-service, and you can get a box that not only takes care of all or almost all your backups, but also lets users themselves quickly sort out most of their data recovery needs.

Changes in the way businesses buy technology are also affecting disaster recovery.

Hyper-converged infrastructure (HCI) started out as a way to make it easier to deploy virtual machines. But because hyper-converged systems usually include their own storage, they lend themselves to disaster recovery too. On-premise HCI systems can be out of the reach of SMEs, but the implementation of cloud-based HCI makes it much more accessible.

An example is Cohesitys Clusters, but Nutanix and Rubrik use similar technologies. Businesses with the in-house expertise can also look at replication to enterprise public cloud providers, such as Amazon Web Services, Microsoft Azure and Google Cloud Platform.

Cloud DR isnt [as] neatly packaged but is more flexible, says Peter Groucutt, managing director of backup provider Databarracks. You can choose your replication software, such as ASR, Zerto or Veeam, and choose your cloud platform. For day-to-day replication you can keep cloud resources to a minimum but have the resources available to scale up as much as you need when you invoke DR.

Another factor in favour of a bespoke approach is the growing need to back up cloud-based applications. The appliance-to-offsite-backup or appliance-to-cloud route is tried and tested, but data backups from cloud-based applications are largely best kept in the cloud.

IT managers should check their disaster recovery plan includes cloud applications. More software-as-a-service (SaaS) providers are including application availability and data protection options with their products.

No amount of technology, though, will protect a business if it fails to work. This means having a disaster recovery plan, a robust testing regimeand a plan to deal with human factors, from the availability of technical experts to senior managements ability to act under pressure.

You must have a robust process that has clear rules on when a switch to disaster recovery is required and when it is not Roy Illsley, Ovum

For SMEs, the main point to consider is ease of use in setting up the replication, and then how the DR capability can be tested and verified it is operating and fit for purpose, says Ovums Illsley. The area where most SMEs fail is in the process for invoking the DR plan. You must have a robust process that has clear rules on when a switch to DR is required and when it is not.

Freeform Dynamics Betts goes further. The absolutely key requirement for DR is to make sure you can recover, he warns. Test it often enough to make sure not just that your backup process is reliable, but that you can rebuild a working system from it within the specified recovery time objective and recovery point objective.

Read more:
SME disaster recovery made easy with cloud, hybrid and HCI - ComputerWeekly.com

When you want to use Linux to provide services to a business, those services will need to be secure, resilient and scalable. Nice words, but what do we mean by them?

Secure means that users can access to the data they require, be that read-only access or write access. At the same time, no data is exposed to any party thats not authorised to see it. Security is deceptive: you can think you have everything protected only to find out later that there are holes. Designing in security from the start of a project is far easier than trying to retrofit it later.

Resilient means your services tolerate failures within the infrastructure. A failure might be a server disk controller that can no longer access any disks, rendering the data unreachable. Or the failure might be a network switch that no longer enables two or more systems to communicate. In this context, a single point of failure or SPOF is a failure that adversely affects service availability. A resilient infrastructure is one with no SPOFs.

Scalable describes the ability of systems to handle spikes of demand gracefully. It also dictates how easily changes may be made to systems. For example, adding a new user, increasing the storage capacity or moving an infrastructure from Amazon Web Services to Google Cloud or even moving it in-house.

As soon as your infrastructure expands beyond one server, there are lots of options for increasing the security, resilience and scalability. Well look at how these problems have been solved traditionally, and what new technology is available that changes the face of big application computing.

(Image credit: Future)

Enjoying what you're reading? Want more Linux and open source? We can deliver, literally! Subscribe to Linux Format today at a bargain price. You can get print issues, digital editions or why not both? We deliver to your door worldwide for a simple yearly fee. So make your life better and easier, subscribe now!

To understand whats possible today, its helpful to look at how technology projects have been traditionally implemented. Back in the olden days that is, more than 10 years ago businesses would buy or lease hardware to run all the components of their applications. Even relatively simple applications, such as a WordPress website, have multiple components. In the case of WordPress, a MySQL database is needed along with a web server, such as Apache, and a way of handling PHP code. So, theyd build a server, set up Apache, PHP and MySQL, install WordPress and off theyd go.

By and large, that worked. It worked well enough that there are still a huge number of servers configured in exactly that way today. But it wasnt perfect, and two of the bigger problems were resilience and scalability.

Lack of resilience meant that any significant issue on the server would result in a loss of service. Clearly a catastrophic failure would mean no website, but there was also no room to carry out scheduled maintenance without impacting the website. Even installing and activating a routine security update for Apache would necessitate a few seconds outage for the website.

The resilience problem was largely solved by building high availability clusters. The principle was to have two servers running the website, configured such that the failure of either one didnt result in the website being down. The service being provided was resilient even if the individual servers were not.

Part of the power of Kubernetes is the abstraction it offers. From a developers perspective, they develop the application to run in a Docker container. Docker doesnt care whether its running on Windows, Linux or some other operating system. That same Docker container can be taken from the developers MacBook and run under Kubernetes without any modification.

The Kubernetes installation itself can be a single machine. Of course, a lot of the benefits of Kubernetes wont be available: there will be no auto-scaling; theres an obvious single point of failure, and so on. As a proof of concept in a test environment, though, it works.

Once youre ready for production, you can run in-house or on a Cloud provider such as AWS or Google Cloud. The Cloud providers have some built-in services that assist in running Kubernetes, but none of are hard requirements. If you want to move between Google, Amazon and your own infrastructure, you set up Kubernetes and move across. None of your applications have to change in any way.

And where is Linux? Kubernetes runs on Linux, but the operating system is invisible to the applications. This is a significant step in the maturity and usability of IT infrastructures.

The scalability problem is a bit trickier. Lets say your WordPress site gets 1,000 visitors a month. One day, your business is mentioned on Radio 4 or breakfast TV. Suddenly, you get more than a months worth of visitors in 20 minutes. Weve all heard stories of websites crashing, and thats typically why: a lack of scalability.

The two servers that helped with resilience could manage a higher workload than one server alone could, but thats still limited. Youd be paying for two servers 100 per cent of the time and most of the time both were working perfectly. Its likely that one alone could run your site. Then John Humphrys mentions your business on Today and youd need 10 servers to handle the load but only for a few hours.

The better solution to both the resilience and scalability problem was cloud computing. Set up a server instance or two the little servers that run your applications on Amazon Web Services (AWS) or Google Cloud, and if one of the instances failed for some reason, it would automatically be restarted. Set up auto-scaling correctly and when Mr Humphrys causes the workload on your web server instances to rapidly rise, additional server instances are automatically started to share the workload. Later, as interest dies down, those additional instances are stopped, and you only pay for what you use. Perfect or is it?

Whilst the cloud solution is much more flexible than the traditional standalone server, there are still issues. Updating all the running cloud instances isnt straightforward. Developing for the cloud has challenges too: the laptop your developers are using may be similar to the cloud instance, but its not the same. If you commit to AWS, migrating to Google Cloud is a complex undertaking. And suppose, for whatever reason, you simply dont want to hand over your computing to Amazon, Google or Microsoft?

Containers have emerged as a means to wrap applications with all of their dependencies up into a single package that can be run anywhere. Containers, such as Docker, can run on your developers laptops in the same way as they run on your cloud instances, but managing a fleet of containers becomes increasingly challenging as the number of containers grows.

The answer is container orchestration. This is a significant shift in focus. Before, we made sure we had enough servers, be they physical or virtual, to ensure we could service the workload. Using the cloud providers autoscaling helped, but we were still dealing with instances. We had to configure load balancers, firewalls, data storage and more manually. With container orchestration, all of that (and much more) is taken care of. We specify the results we require and our container orchestration tools fulfil our requirements. We specify what we want done, rather than how we want it done.

Kubernetes (ku-ber-net-eez) is the leading container orchestration tool today, and it came from Google. If anyone knows how to run huge-scale IT infrastructures, Google does. The origin of Kubernetes is Borg, an internal Google project thats still used to run most of Googles applications including its search engine, Gmail, Google Maps and more. Borg was a secret until Google published a paper about it in 2015, but the paper made it very apparent that Borg was the principal inspiration behind Kubernetes.

Borg is a system that manages computational resources in Googles data centres and keeps Googles applications, both production and otherwise, running despite hardware failure, resource exhaustion or other issues occurring that might otherwise have caused an outage. It does this by carefully monitoring the thousands of nodes that make up a Borg cell and the containers running on them, and starting or stopping containers as required in response to problems or fluctuations in load.

Kubernetes itself was born out of Googles GIFEE (Googles Infrastructure For Everyone Else) initiative, and was designed to be a friendlier version of Borg that could be useful outside Google. It was donated to the Linux Foundation in 2015 through the formation of the Cloud Native Computing Foundation (CNCF).

Kubernetes provides a system whereby you declare your containerised applications and services, and it makes sure your applications run according to those declarations. If your programs require external resources, such as storage or load balancers, Kubernetes can provision those automatically. It can scale your applications up or down to keep up with changes in load, and can even scale your whole cluster when required. Your programs components dont even need to know where theyre running: Kubernetes provides internal naming services to applications so that they can connect to wp_mysql and be automatically connected to the correct resource.

The end result is a platform that can be used to run your applications on any infrastructure, from a single machine through an on-premise rack of systems to cloud-based fleets of virtual machines running on any major cloud provider, all using the same containers and configuration. Kubernetes is provider-agnostic: run it wherever you want.

Kubernetes is a powerful tool, and is necessarily complex. Before we get into an overview, we need to introduce some terms used within Kubernetes. Containers run single applications, as discussed above, and are grouped into pods. A pod is a group of closely linked containers that are deployed together on the same host and share some resources. The containers within a pod work as a team: theyll perform related functions, such as an application container and a logging container with specific settings for the application.

Four key Kubernetes components are the API Server, the Scheduler, the Controller Manager and a distributed configuration database called etcd. The API Server is at the heart of Kubernetes, and acts as the primary endpoint for all management requests. These may be generated by a variety of sources including other Kubernetes components, such as the scheduler, administrators via command-line or web-based dashboards, and containerised applications themselves. It validates requests and updates data stored in etcd.

The Scheduler determines which nodes the various pods will run on, taking into account constraints such as resource requirements, any hardware or software constraints, workload, deadlines and more.

The Controller Manager monitors the state of the cluster, and will try to start or stop pods as necessarily, via the API Server, to bring the cluster to the desired state. It also manages some internal connections and security features.

Each node runs a Kubelet process, which communicates with the API server and manages containers generally using Docker and Kube-Proxy, which handles network proxying and load balancing within the cluster.

The etcd distributed database system derives its name from the /etc folder on Linux systems, which is used to hold system configuration information, plus the suffix d, often used to denote a daemon process. The goals of etcd are to store key-value data in a distributed, consistent and fault-tolerant way.

The API server keeps all its state data in etcd and can run many instances concurrently. The scheduler and controller manager can only have one active instance but uses a lease system to determine which running instance is the master. All this means that Kubernetes can run as a Highly Available system with no single points of failure.

So how do we use those components in practice? What follows is an example of setting up a WordPress website using Kubernetes. If you wanted to do this for real, then youd probably use a predefined recipe called a helm chart. They are available for a number of common applications, but here well look at some of the steps necessary to get a WordPress site up and running on Kubernetes.

The first task is to define a password for MySQL:

kubectl will talk to the API Server, which will validate the command and then store the password in etcd. Our services are defined in YAML files, and now we need some persistent storage for the MySQL database.

The specification should be mostly self-explanatory. The name and labels fields are used to refer to this storage from other parts of Kubernetes, in this case our WordPress container.

Once weve defined the storage, we can define a MySQL instance, pointing it to the predefined storage. Thats followed by defining the database itself. We give that database a name and label for easy reference within Kubernetes.

Now we need another container to run WordPress. Part of the container deployment specification is:

The strategy type Recreate means that if any of the code comprising the application changes, then running instances will be deleted and recreated. Other options include being able to cycle new instances in and removing existing instances, one by one, enabling the service to continue running during deployment of an update. Finally, we declare a service for WordPress itself, comprising the PHP code and Apache. Part of the YAML file declaring this is:

Note the last line, defining service type as LoadBalancer. That instructs Kubernetes to make the service available outside of Kubernetes. Without that line, this would merely be an internal Kubernetes only service. And thats it. Kubernetes will now use those YAML files as a declaration of what is required, and will set up pods, connections, storage and so on as required to get the cluster into the desired state.

This has necessarily been only a high-level overview of Kubernetes, and many details and features of the system have been omitted. Weve glossed over autoscaling (both pods and the nodes that make up a cluster), cron jobs (starting containers according to a schedule), Ingress (HTTP load balancing, rewriting and SSL offloading), RBAC (role-based access controls), network policies (firewalling), and much more. Kubernetes is extremely flexible and extremely powerful: for any new IT infrastructure, it must be a serious contender.

If youre not familiar with Docker start here: https://docs.docker.com/get-started.

Theres an interactive, tutorial on deploying and scaling an app here: https://kubernetes.io/docs/tutorials/kubernetes-basics.

And see https://kubernetes.io/docs/setup/scratch for how to build a cluster.

You can play with a free Kubernetes cluster at https://tryk8s.com.

Finally, you can pore over a long, technical paper with an excellent overview of Googles use of Borg and how that influenced the design of Kubernetes here: https://storage.googleapis.com/pub-tools-public-publication-data/pdf/43438.pdf.

Find out more about Tiger Computing.

(Image credit: Future)

Enjoying what you're reading? Want more Linux and open source? We can deliver, literally! Subscribe to Linux Format today at a bargain price. You can get print issues, digital editions or why not both? We deliver to your door worldwide for a simple yearly fee. So make your life better and easier, subscribe now!

Here is the original post:
Kubernetes - taming the cloud - TechRadar

Inspur is showcasing new HPC systems with Natural Circulation Evaporative Cooling technology this week at SC19. Inspur combines high-density computing servers with natural circulation evaporative cooling technology, which is more reliable, energy-saving, and easier to deploy than other liquid cooling solutions.

Currently, HPC is in urgent need of cooling technologies with high efficiency and lower energy consumption. However, the cost, safety, deployment and maintenance challenges of cooling solutions are big concerns of users. Liquid cooling technologies, compared to traditional air cooling counterparts, boast prominent advantages in heat dissipation efficiency, energy utilization, and other aspects, and have seen rapid growth in recent years. Nevertheless, liquid cooling technologies are still subject to challenges. For example, immersion and spray-type liquid cooling technologies, despite their more efficient heat dissipation, require to have the IT components continuously observed to maintain the functionality and reliability because of direct contact with the coolant. Moreover, excessive usage of coolant pushes the limit on machine room load-bearing capacity, and raises operation and maintenance costs. Plate-type water cooling technology, though not exposed to heating elements directly, uses uninsulated water as the coolant which, once leaked, will cause lethal damage to HPC systems, giving rise to safety hazards.

Inspur collaborated with the Institute of Electrical Engineering of Chinese Academy of Sciences (IEECAS), combining Inspurs leading supercomputing servers with IEECASs natural circulation evaporative cooling technology to achieve an efficient, reliable and energy saving liquid cooling HPC system. The system is equipped with Inspurs high-density server i24 which can support 4 high-performance two-socket computing nodes in 2U and the natural circulation evaporative cooling suite developed by IEECAS. The natural circulation evaporation method requires no circulating pumps which are necessary in traditional plate-type water cooling but vulnerable and energy consuming and enables automatic control over condenser fans, eliminating manual operation for over 90% of the time. This further reduces cooling overheads and lowers the PUE values of data centers to below 1.1 for green and energy-efficient operation. The non-corrosive insulating cooling liquid protects IT devices from damage in the event of leakages, greatly improving safety. In addition, the entire cooling system is compact in size and easy to deploy and maintain, with less demanding requirements on machine rooms.

The cooling system has already been successfully deployed in a large science project and is performing as expected.

Inspur is a leading provider of data center infrastructure, cloud computing, and AI solutions, ranking among the worlds top 3 server manufacturers. Through engineering and innovation, Inspur delivers cutting-edge computing hardware design and extensive product offerings to address important technology arenas like open computing, cloud data center, AI and deep learning. Performance-optimized and purpose-built, our world-class solutions empower customers to tackle specific workloads and real-world challenges.

See our complete coverage of SC19

Check out our insideHPC Events Calendar

See the article here:
Inspur steps up with Innovative Liquid Cooling Technology at SC19 - insideHPC

The definition for the cloud can seem murky, but essentially, its a term used to describe a global network of servers, each with a unique function. The cloud is not a physical entity, but instead is a vast network of remote servers around the globe which are hooked together and meant to operate as a single ecosystem. These servers are designed to either store and manage data, run applications, or deliver content or a service such as streaming videos, web mail, office productivity software, or social media. Instead of accessing files and data from a local or personal computer, you are accessing them online from any Internet-capable devicethe information will be available anywhere you go and anytime you need it.

Businesses use four different methods to deploy cloud resources. There is a public cloud that shares resources and offers services to the public over the Internet, a private cloud that isnt shared and offers services over a private internal network typically hosted on-premises, a hybrid cloud that shares services between public and private clouds depending on their purpose, and a community cloud that shares resources only between organizations, such as with government institutions.

View post:
What is the Cloud - Definition | Microsoft Azure

A cloud server is a hosted, and typically virtual, compute server that is accessed by users over a network. Cloud servers are intended to provide the same functions, support the same operating systems (OSes) and applications, and offer performance characteristics similar to traditional physical servers that run in a local data center. Cloud servers are often referred to as virtual servers, virtual private servers or virtual platforms.

An enterprise can choose from several types of cloud servers. Three primary models include:

Public cloud servers: The most common expression of a cloud server is a virtual machine (VM) -- or compute "instance" -- that a public cloud provider hosts on its own infrastructure, and delivers to users across the internet using a web-based interface or console. This model is broadly known as infrastructure as a service (IaaS). Common examples of cloud servers include Amazon Elastic Compute Cloud instances, Azure instances and Google Compute Engine instances.

Private cloud servers: A cloud server may also be a compute instance within an on-premises private cloud. In this case, an enterprise delivers the cloud server to internal users across a local area network, and, in some cases, also to external users across the internet. The primary difference between a hosted public cloud server and a private cloud server is that the latter exists within an organization's own infrastructure, where a public cloud server is owned and operated outside of the organization.

Dedicated cloud servers: In addition to virtual cloud servers, cloud providers can also supply physical cloud servers, also known as bare-metal servers, which essentially dedicate a cloud provider's physical server to a user. These dedicated cloud servers also called dedicated instances -- are typically used when an organization must deploy a custom virtualization layer, or mitigate the performance and security concerns that often accompany a multi-tenant cloud server.

Cloud servers are available in a wide array of compute options, with varying amounts of processors and memory resources. This enables a user to select an instance type that best fits the needs of a specific workload. For example, a smaller Amazon EC2 instance might offer one virtual CPU and 2 GB of memory, while a larger Amazon EC2 instance provides 96 virtual CPUs and 384 GB of memory. In addition, it is possible to find cloud server instances that are tailored to unique workload requirements, such as compute-optimized instances that include more processors relative to the amount of memory.

While it's common for traditional physical servers to include some storage, most public cloud servers do not include storage resources. Instead, cloud providers typically offer storage as a separate cloud service, such as Amazon Simple Storage Service and Google Cloud Storage. A user provisions and associates storage instances with cloud servers to hold content, such as VM images and application data.

The choice to use a cloud server will depend on the needs of the organization and its specific application and workload requirements. Some potential benefits and drawbacks include:

Ease of use: One of the biggest benefits of cloud servers is that a user can provision them in a matter of minutes. With a public cloud server, an organization does not need to worry about server installation, maintenance or other tasks that come with ownership of a physical server.

Globalization: Public cloud servers can "globalize" workloads. With a traditional centralized data center, users can still access workloads globally, but network latency and disruptions can reduce performance for geographically distant users. By hosting duplicate instances of a workload in different global regions, users can benefit from faster and often more reliable access.

Cost: Public cloud servers follow a pay-as-you-go pricing model. Compared to a traditional physical server, this can save an organization money, particularly for workloads that only need to run temporarily or are used infrequently. Cloud servers are often used in such temporary use cases, such as software development and testing, as well as where high scalability is important. However, depending on the amount of use, the long-term and full-time cost of cloud servers can become more expensive than owning the server outright. In addition, regulatory obligations and corporate governance standards may prohibit organizations from using cloud servers and storing data in different geographic regions.

Performance: Because cloud severs are typically multi-tenant environments, and a user has no direct control over those servers' physical location, a VM may be adversely impacted by excessive storage or network demands of other cloud servers on the same hardware. This is often referred to as the "noisy neighbor" issue. Dedicated or bare-metal cloud servers can help a user avoid this problem.

Outages and resilience: Cloud servers are subject to periodic and unpredictable service outages, usually due to a fault within the provider's environment or an unexpected network disruption. For this reason, and because a user has no control over a cloud provider's infrastructure, some organizations choose to keep mission-critical workloads within their local data center rather than the public cloud. Also, there is no inherent high availability or redundancy in public clouds. Users that require greater availability for a workload must deliberately architect that availability into the workload.

Continued here:
What is cloud server? - Definition from WhatIs.com