Hands-On Linux for Architects

Design and implement Linux-based IT solutions

Denis Salamanca, Esteban Flores

• Publisher: Packt Publishing
• Year: 2019
• ISBN:
  9781789532296
• Edition: 1
• Topic: Computer Science
• Subtopic: Operating Systems
• Index: Computer Science

Explore practical use cases to learn everything from Linux components, and functionalities, through to hardware and software support

Key Features

• Gain a clear understanding of how to design a Linux environment
• Learn more about the architecture of the modern Linux operating system(OS)
• Understand infrastructure needs and design a high-performing computing environment

Book Description

It is very important to understand the flexibility of an infrastructure when designing an efficient environment. In this book, you will cover everything from Linux components and functionalities through to hardware and software support, which will help you to implement and tune effective Linux-based solutions.

This book gets started with an overview of Linux design methodology. Next, you will focus on the core concepts of designing a solution. As you progress, you will gain insights into the kinds of decisions you need to make when deploying a high-performance solution using Gluster File System (GlusterFS). In the next set of chapters, the book will guide you through the technique of using Kubernetes as an orchestrator for deploying and managing containerized applications. In addition to this, you will learn how to apply and configure Kubernetes for your NGINX application. You'll then learn how to implement an ELK stack, which is composed of Elasticsearch, Logstash, and Kibana. In the concluding chapters, you will focus on installing and configuring a Saltstack solution to manage different Linux distributions, and explore a variety of design best practices. By the end of this book, you will be well-versed with designing a high-performing computing environment for complex applications to run on.

By the end of the book, you will have delved inside the most detailed technical conditions of designing a solution, and you will have also dissected every aspect in detail in order to implement and tune open source Linux-based solutions

What you will learn

• Study the basics of infrastructure design and the steps involved
• Expand your current design portfolio with Linux-based solutions
• Discover open source software-based solutions to optimize your architecture
• Understand the role of high availability and fault tolerance in a resilient design
• Identify the role of containers and how they improve your continuous integration and continuous deployment pipelines
• Gain insights into optimizing and making resilient and highly available designs by applying industry best practices

Who this book is for

This intermediate-level book is for Linux system administrators, Linux support engineers, DevOps engineers, Linux consultants or any open source technology professional looking to learn or expand their knowledge in architecting, designing and implementing solutions based on Linux and open source software. Prior experience in Linux is required.

Section 1: High-Performance Storage Solutions with GlusterFS

In this section, the reader will be able to understand the decisions needed to be made when deploying a high-performance storage solution using GlusterFS.

This section contains the following chapters:

• Chapter 1, Introduction to Design Methodology
• Chapter 2, Defining GlusterFS Storage
• Chapter 3, Architecting a Storage Cluster
• Chapter 4, Using GlusterFS on the Cloud Infrastructure
• Chapter 5, Analyzing Performance in a Gluster System

Introduction to Design Methodology

These days, IT solutions require increased performance and data availability, and designing a robust implementation that meets these requirements is a challenge that many IT experts have to go through every day.

In this chapter, you will learn the basics, from a bird's-eye view of architecting IT solutions in any type of environment, to virtualized infrastructure, bare metal, and even the public cloud, as basic concepts of solution design apply to any environment.

You will explore the following subjects:

• Defining the stages of solution design and why they matter
• Analyzing the problem and asking the right questions
• Considering possible solutions
• Implementing the solution

Fully understanding the aspects that you need to consider when architecting a solution is crucial for the success of the project, as this will determine which software, hardware, and configuration will help you achieve the desired state that meets the needs of your customers.

Defining the stages of solution design and why they matter

Like many things, designing solutions is a step-by-step process that not only involves: technical aspects, nor necessarily technical parties. Usually, you will be engaged by an account manager, project manager, or, if you are lucky, a CTO, who understands the technical part of the requirements. They are looking for an expert who can help them deliver a solution to a customer. These requests usually do not contain all the information you will need to deliver your solution, but it's a start to understand what your goal is.

For example, imagine that you receive an email from a project manager with the following statement.

We require a solution that can sustain at least 10,000 website hits and will stay available during updates as well as survive outages. Our budget is considerably low, so we need to spend as little as possible, with little to no upfront cost. We're also expecting this to gain momentum during the project's life cycle.

From the previous statement, you can only get a general idea of what is required, but no specifics have been given. So, you only know basic information: we require a solution that can sustain at least 10,000 website hits, which, for a design, is not good enough, as you require as much information as possible to be able to resolve the problems exposed by your customer. This is where you have to ask for as many details as possible to be able to provide an accurate set of proposals for your customer, which will be the first impression your customer will have of the project. This part is critical, as it will help you understand whether you understand your customer's vision.

It is also important to understand that you need to deliver several different solutions for the customer, as the customer is the one who decides which one fits their business needs the most. Remember that each solution has its own advantages and disadvantages. After the customer decides which way to go, you will have what is necessary to move on to the implementation of your proposal, which can always trigger more challenges. It will require, more often than not, some final customized tuning or changes that were not considered in the initial Proof of Concept (POC).

From our previous analysis, you can see four well-defined stages of the process that you need to follow in order to reach the final delivery illustrated in the following diagram:

There are many more stages and design methodologies that we could cover, but since they're not in the scope of this book, we will be focusing on these four general stages to help you understand the process in which you will be architecting your solutions.

Analyzing the problem and asking the right questions

After getting the initial premise, you need to break it into smaller pieces in order to understand what is required. Each piece will raise different questions that you will ask your customers later. These questions will help fill in the gaps for your POC, ensuring that your questions cover all business needs from all view standpoints: the business standpoint, the functional standpoint, and, finally, the technical standpoint. One good way to keep track of the questions that arise and which business need they will be resolving is to have a checklist that asks which standpoint the question is being asked from and what is resolved or answered.

It is also important to note that, as questions become answers, they can also come with constraints or other obstacles that will also need to be addressed and mentioned during the POC stage. The customer will have to agree with them and will be decisive when selecting the final solution.

From our previous example, you can analyze the premise by dissecting it into standpoints.

We require a solution that can sustain at least 10,000 website hits and will stay available during updates as well as survive outages. Our budget is considerably low, so we need to spend as little as possible, with little to no upfront cost. We're also expecting this to gain momentum during the project's life cycle.

Technical standpoint

From this perspective, we will analyze all technical aspects of the premise – anything that you will need to provide the initial technical requirements of your solution.

We will analyze it in the following way:

• You can understand, from the premise, that your customer needs some kind of solution that can sustain some amount of website hits, but you can't be certain if the web server is already set up, and whether the customer only needs a load balancing solution. Alternatively, maybe the customer needs both, a web server, that is NGINX, Apache, or something of that sort, and the load balancing solution.
• The customer mentions at least 10,000 hits to their website, but they didn't mention if these hits are concurrent per second, daily, weekly, or even monthly.
• You can also see that they need to stay available during updates and be able to continue serving their website if the company has an outage, but all these statements are very general, since availability is measured in 9s. The more 9s you have, the better (in reality, this is a percentage measurement of the amount of time during the year; a 99% availability means that there can only be 526 minutes of downtime per year). Outages are also very hard to predict, and it's almost impossible to be able to say that you will never have an outage, therefore, you need to plan for it. You have to have a Recovery point objective (RPO) and a Recovery time objective (RTO) for your solution in case of a disaster. The customer didn't mention this, and it is crucial to understand how much time a business can sustain an outage.
• When it comes to budget, this is usually from a business perspective, but the technical aspects are affected directly by it. It looks like the budget in the project is tight, and the customer wants to spend as little as possible on their solution, but they're not mentioning exact numbers, which you will require in order to fit your proposals to it. Little to no upfront cost? What does this mean? Are we repurposing the existing resources and building a new solution? How can we implement a design with no upfront cost? One way to overcome low budgets, or no upfront costs, at least in software, is to utilize open source software (OSS), but this is something that we need to ask the customer.
• Gaining momentum can only mean that they are predicting that their userbase will grow eventually, but you need an estimate of how much they predict this will grow and how fast, as this will imply that you have to leave the solution ready to be scaled vertically or horizontally. Vertically, by leaving space to increase the resources eventually and take into account the business's procurement process if you need to buy more resources such RAM, CPU, or storage. Horizontally will also involve a procurement process and a considerable amount of time to integrate a new node/server/VM/container into the solution. None of these are included in the premise, and it's vital information.

Here, we have a comparison of horizontal and vertical scaling. Horizontal scaling adds more nodes, while vertical scaling adds more resources to the existing nodes:

The following is a list of example questions that you could ask to clarify the gray areas:

• Is this solution for a new/existing website or web server?
• When you say 10,000 hits, are these concurrent per second or is it daily/weekly/monthly?
• Do you have any estimates or current data of how large your userbase is?
• Considering that the budget is low, can we use OSS?
• Do you ha...

Table of contents

• Title Page
• Copyright and Credits
• About Packt
• Contributors
• Dedication
• Preface
• Section 1: High-Performance Storage Solutions with GlusterFS
• Introduction to Design Methodology
• Defining GlusterFS Storage
• Architecting a Storage Cluster
• Using GlusterFS on the Cloud Infrastructure
• Analyzing Performance in a Gluster System
• Section 2: High-Availablility Nginx Web Application Using Kubernetes
• Creating a Highly Available Self-Healing Architecture
• Understanding the Core Components of a Kubernetes Cluster
• Architecting a Kubernetes Cluster
• Deploying and Configuring Kubernetes
• Section 3: Elastic Stack
• Monitoring with the ELK Stack
• Designing an ELK Stack
• Using Elasticsearch, Logstash, and Kibana to Manage Logs
• Section 4: System Management Using Saltstack
• Solving Management Problems with Salty Solutions
• Getting Your Hands Salty
• Design Best Practices
• Assessments
• Other Books You May Enjoy