mirror of
https://github.com/opsschool/curriculum.git
synced 2025-12-06 00:19:45 +01:00
Mega trailing whitespace commit
This commit is contained in:
parent
4696176936
commit
15ffe051d7
|
|
@ -7,7 +7,7 @@ this course)
|
|||
Fundamentals of capacity planning
|
||||
=================================
|
||||
|
||||
Resource usage investigation and exploration
|
||||
Resource usage investigation and exploration
|
||||
---------------------------------------------
|
||||
|
||||
* Examples: CPU:req/sec ratio, memory footprint:req/sec ratio, disk consumption
|
||||
|
|
@ -19,7 +19,7 @@ Resource usage investigation and exploration
|
|||
Finding ceilings
|
||||
----------------
|
||||
|
||||
* Discovering resource limits
|
||||
* Discovering resource limits
|
||||
* Comparing different hardware/instance profiles - production load versus
|
||||
synthetic
|
||||
|
||||
|
|
@ -30,7 +30,7 @@ Finding ceilings
|
|||
uploads, caching storage+processing, etc.
|
||||
* Architecture analysis (anticipating the next bottleneck)
|
||||
|
||||
Forecasting
|
||||
Forecasting
|
||||
============
|
||||
|
||||
Linear and nonlinear trending and forecasting ("steering by your wake")
|
||||
|
|
@ -44,8 +44,8 @@ Seasonality and future events
|
|||
|
||||
* Organic growth approaches (bottom-up infra driven, top-down app driven)
|
||||
* inorganic growth events (new feature launch, holiday effects, "going viral",
|
||||
major public announcement)
|
||||
* Provisioning effects on timelines, financial tradeoffs
|
||||
major public announcement)
|
||||
* Provisioning effects on timelines, financial tradeoffs
|
||||
|
||||
Diagonal scaling
|
||||
================
|
||||
|
|
|
|||
|
|
@ -121,7 +121,7 @@ servers, operating systems, databases, middleware and applications.
|
|||
|
||||
Systems Administrators can range from "jack of all trades" with knowledge of
|
||||
multiple systems and platforms to specialists who focus on one system or
|
||||
platform, for example Microsoft Windows or Linux.
|
||||
platform, for example Microsoft Windows or Linux.
|
||||
|
||||
Whilst perhaps more "general" than some of the other specialist roles, Systems
|
||||
Administrators tend to focus on managing individual hosts, usually desktops or
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ Tools: Speaking http with telnet/netcat/curl
|
|||
============================================
|
||||
|
||||
Understanding how a browser/tool parses a url and server receives it for a
|
||||
request
|
||||
request
|
||||
|
||||
Apache, nginx
|
||||
=============
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ Rails
|
|||
Sinatra
|
||||
-------
|
||||
|
||||
Python
|
||||
Python
|
||||
======
|
||||
|
||||
Django
|
||||
|
|
|
|||
2
labs.rst
2
labs.rst
|
|
@ -240,5 +240,5 @@ Install Apache
|
|||
Configure a virtual host
|
||||
------------------------
|
||||
|
||||
Display a simple web page
|
||||
Display a simple web page
|
||||
--------------------------
|
||||
|
|
|
|||
|
|
@ -9,14 +9,14 @@ Why do we use load balancers?
|
|||
* They keep application servers busy by buffering responses and serving them to
|
||||
slow clients (or keepalives). We want app servers to do real work, not waste
|
||||
time waiting on the network.
|
||||
* Load balancers provide a mechanism to verify the health of backend servers to
|
||||
* Load balancers provide a mechanism to verify the health of backend servers to
|
||||
ensure traffic is only routed to backends available to service the request.
|
||||
These health checks can be simplistic ICMP pings to ensure host availability
|
||||
to advanced HTTP (layer 7) health checks that use HTTP response codes or
|
||||
to advanced HTTP (layer 7) health checks that use HTTP response codes or
|
||||
content matching.
|
||||
* Can provide a layer of abstraction such that end user endpoints remain
|
||||
consistent (i.e URLs) as backend application infrastructure expands
|
||||
(or contracts)
|
||||
* Can provide a layer of abstraction such that end user endpoints remain
|
||||
consistent (i.e URLs) as backend application infrastructure expands
|
||||
(or contracts)
|
||||
* Can be either software based (aka reverse proxies) or hardware based (physical
|
||||
devices optimized for network throughput and ISO layer 2,3 and 4 routing).
|
||||
* Can be tuned by itself for max conns?
|
||||
|
|
@ -34,7 +34,7 @@ An application server behind a load balancer is typically referred to as a
|
|||
Pools
|
||||
-----
|
||||
|
||||
A collection of backends is referred to as a pool.
|
||||
A collection of backends is referred to as a pool.
|
||||
|
||||
Balancing algorithms
|
||||
--------------------
|
||||
|
|
@ -42,7 +42,7 @@ Balancing algorithms
|
|||
Session Affinity
|
||||
----------------
|
||||
|
||||
Session affinity or session stickiness, is when the load balancer applies an
|
||||
Session affinity or session stickiness, is when the load balancer applies an
|
||||
algorithm to the incoming connection to direct it to a single server. This
|
||||
is typically done for HTTP applications by setting cookies. In general TCP
|
||||
applications often use IP addresses to determine the server to direct
|
||||
|
|
@ -54,34 +54,34 @@ Local & ISP caching
|
|||
SSL Termination and Offloading
|
||||
------------------------------
|
||||
|
||||
SSL Termination is when the load balancer established an SSL connection
|
||||
SSL Termination is when the load balancer established an SSL connection
|
||||
between the client and the load balancer and a non-encrypted connection between
|
||||
the load balancer and backend server.
|
||||
|
||||
Terminating SSL on the load balancer eliminates the need to distribute your
|
||||
Terminating SSL on the load balancer eliminates the need to distribute your
|
||||
certificate and key amongst all the servers. When using hardware load balancers
|
||||
they typically have special hardware acceleration which is much more performant
|
||||
compared to terminating connections on the backend server.
|
||||
they typically have special hardware acceleration which is much more performant
|
||||
compared to terminating connections on the backend server.
|
||||
|
||||
Balancing vs. Failover (Active / Passive)
|
||||
-----------------------------------------
|
||||
|
||||
Often load balancing is used as a high-availability technique, by allowing
|
||||
multiple backends to service a request if one node should become unavailable. It
|
||||
differs from failover configuration because all nodes generally participate in
|
||||
servicing clients. In failover configurations a single (active) node handles all
|
||||
requests until an issue arises, and the secondary (passive) node takes over all
|
||||
differs from failover configuration because all nodes generally participate in
|
||||
servicing clients. In failover configurations a single (active) node handles all
|
||||
requests until an issue arises, and the secondary (passive) node takes over all
|
||||
of the incoming traffic. Failover configurations are usually not configured for
|
||||
scaling purposes.
|
||||
scaling purposes.
|
||||
|
||||
Health Checks
|
||||
Health Checks
|
||||
---------------
|
||||
|
||||
Most load balancers have some ability to test backend servers for availability,
|
||||
these are called health checks. They can be as simple as whether hosts are
|
||||
Most load balancers have some ability to test backend servers for availability,
|
||||
these are called health checks. They can be as simple as whether hosts are
|
||||
responding on the port the application is bound to, or complex configurations
|
||||
that test special URIs, or response times. If a server fails a health check the
|
||||
load balancer will temporarily remove the node from the pool, until it
|
||||
load balancer will temporarily remove the node from the pool, until it
|
||||
successfully passes the health check.
|
||||
|
||||
Non-HTTP use cases
|
||||
|
|
@ -95,11 +95,11 @@ Software
|
|||
Apache
|
||||
------
|
||||
|
||||
Apache has the ability to load balance using ``mod_proxy_balancer``, and ``mod_jk``.
|
||||
Apache has the ability to load balance using ``mod_proxy_balancer``, and ``mod_jk``.
|
||||
|
||||
Mod_poxy_balancer is purpose-built load balancing solution. It supports the HTTP, FTP,
|
||||
and AJP protocols. There is basic support for sessions stickiness's, weighted round-robin,
|
||||
and can remove unhealthy backends from the balancing pool. It lacks support for customizable
|
||||
and AJP protocols. There is basic support for sessions stickiness's, weighted round-robin,
|
||||
and can remove unhealthy backends from the balancing pool. It lacks support for customizable
|
||||
health checks, other TCP protocols. Support for AJP is provided by ``mod_proxy_ajp`` and support
|
||||
for FTP is provided by ``mod_proxy_ftp``.
|
||||
|
||||
|
|
@ -115,12 +115,12 @@ Nginx
|
|||
HAProxy
|
||||
-------
|
||||
|
||||
HAProxy is a general TCP load balancing server that is highly configurable. It
|
||||
will generally support any TCP based protocol, and has special modes for HTTP,
|
||||
RDP, MySQL, and Postgresql protocols. It has support for multiple types of
|
||||
HAProxy is a general TCP load balancing server that is highly configurable. It
|
||||
will generally support any TCP based protocol, and has special modes for HTTP,
|
||||
RDP, MySQL, and Postgresql protocols. It has support for multiple types of
|
||||
health check including URL based, traffic-based health, and external checks via
|
||||
the ``httpchk`` options. It has several load balancing algorithms: round robin,
|
||||
static round-robin, least connections, source hashing, URI hashing, URI
|
||||
static round-robin, least connections, source hashing, URI hashing, URI
|
||||
parameter, and RDP-cookie.
|
||||
|
||||
|
||||
|
|
@ -130,10 +130,10 @@ Hardware
|
|||
BIG-IP
|
||||
------
|
||||
|
||||
BIG-IP has purpose-built hardware load balancers. They support protocols in layers
|
||||
2, 4, and 7 of the OSI model. They allow for very complex configurations, and
|
||||
BIG-IP has purpose-built hardware load balancers. They support protocols in layers
|
||||
2, 4, and 7 of the OSI model. They allow for very complex configurations, and
|
||||
support writing special TCL programs to modify the load balancing behavior. The
|
||||
product supports SSL termination and offloading, with additional licensing.
|
||||
product supports SSL termination and offloading, with additional licensing.
|
||||
|
||||
Netscaler
|
||||
---------
|
||||
|
|
@ -146,14 +146,14 @@ Anycast
|
|||
|
||||
DNS GSLB
|
||||
--------
|
||||
* A GSLB (Global Site Load Balancer) at the most simplistic level is a health
|
||||
* A GSLB (Global Site Load Balancer) at the most simplistic level is a health
|
||||
checking DNS server.
|
||||
* Most often used to load balance between geographically dispersed data centers.
|
||||
* Generally has health check mechanisms similar to load balancers which are used
|
||||
to return an IP address (as part of the DNS lookup) of a host that is currently
|
||||
available to service the request.
|
||||
* Conceptually provides coarse-grained round robin and affinity balancing
|
||||
algorithms by setting the time to live (TTL) of the DNS lookup for an
|
||||
algorithms by setting the time to live (TTL) of the DNS lookup for an
|
||||
appropriate duration.
|
||||
|
||||
CDN's
|
||||
|
|
|
|||
|
|
@ -98,7 +98,7 @@ IPv4 uses a 32-bit address space most typically represented in 4 dotted decimal
|
|||
each octet contains a value between 0-255, and is separated by a dot. An example
|
||||
address is below:
|
||||
|
||||
10.199.0.5
|
||||
10.199.0.5
|
||||
|
||||
There are several other representations, like dotted hexadecimal, dotted octal, hexadecimal,
|
||||
decimal, and octal. These are infrequently used, and will be covered in later sections.
|
||||
|
|
@ -120,7 +120,7 @@ Subnetting, netmasks and CIDR
|
|||
A subnet is a logical division of an IP network, and allows the host system to identify which
|
||||
other hosts can be reached on the local network. The host system determines
|
||||
this by the application of a routing prefix. There are two typical representations of this
|
||||
prefix: a netmask and CIDR.
|
||||
prefix: a netmask and CIDR.
|
||||
|
||||
Netmasks typically appear in the dotted decimal notation, with values between 0-255 in each
|
||||
octet. These are applied as bitmasks, and numbers at 255 mean that this host is not reachable.
|
||||
|
|
@ -128,9 +128,9 @@ Netmask can also be referred to as a Subnet Mask and these terms are often used
|
|||
example IP Address with a typical netmask is below:
|
||||
|
||||
============= ===============
|
||||
IP Address Netmask
|
||||
IP Address Netmask
|
||||
============= ===============
|
||||
192.168.1.1 255.255.255.0
|
||||
192.168.1.1 255.255.255.0
|
||||
============= ===============
|
||||
|
||||
CIDR notation is a two-digit representation of this routing prefix. Its value can range
|
||||
|
|
@ -138,9 +138,9 @@ between 0 and 32. This representation is typically used for networking equipment
|
|||
is the same example as above with CIDR notation:
|
||||
|
||||
============= ===============
|
||||
IP Address CIDR
|
||||
IP Address CIDR
|
||||
============= ===============
|
||||
192.168.1.1 /24
|
||||
192.168.1.1 /24
|
||||
============= ===============
|
||||
|
||||
Private address space (:rfc:`1918`)
|
||||
|
|
@ -173,9 +173,9 @@ Practical networking
|
|||
Cat5e, Cat6, Cat6a
|
||||
------------------
|
||||
|
||||
Cat5e, Cat6, and Cat6a are all coper transport mediums. They use twisted pair
|
||||
Cat5e, Cat6, and Cat6a are all coper transport mediums. They use twisted pair
|
||||
wiring, relying on the twist with differential signaling to prevent noise. This is the most
|
||||
common form of cabling for connecting computers in a network.
|
||||
common form of cabling for connecting computers in a network.
|
||||
|
||||
Fiber
|
||||
-----
|
||||
|
|
@ -187,16 +187,16 @@ Multimode vs Single Mode vs OM{3,4}
|
|||
Multimode fiber is a less expensive fiber optic cable, that is typically useable with lower
|
||||
cost optical components. Depending on the application and bandwidth required, multimode fiber
|
||||
can have a range up to 2000 meters, but as low as 33 meters. It is very common to see it
|
||||
used for building backbones, and system to switch applications.
|
||||
used for building backbones, and system to switch applications.
|
||||
|
||||
LC vs SC
|
||||
^^^^^^^^
|
||||
|
||||
LC and SC connectors are the two most common type of fiber connectors.
|
||||
LC and SC connectors are the two most common type of fiber connectors.
|
||||
|
||||
LC is also known as a Lucent Connector. They are typically used for high-density applications, and are
|
||||
the type of connector used on SFPs or XFPs. Typically the connector is packaged in a duplex configuration
|
||||
with each cable side by side.
|
||||
with each cable side by side.
|
||||
|
||||
SC connectors are also know as Subscriber Connector, Square Connector, or Standard Connector. This is the type
|
||||
of connector typically used in the telecom industry. They have a larger form factor than the LC connectors, and
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ I/O
|
|||
Pipes
|
||||
-----
|
||||
|
||||
stderr vs. stdout
|
||||
stderr vs. stdout
|
||||
------------------
|
||||
|
||||
/dev/null and /dev/zero
|
||||
|
|
|
|||
|
|
@ -77,13 +77,13 @@ To list all of the shell's environment variables, use the ``env`` command: ::
|
|||
PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:/usr/local/bin
|
||||
MAIL=/var/spool/mail/root
|
||||
PWD=/root/curriculum
|
||||
PS1=[\[\e[33;1m\]\t \[\e[31;1m\]\u\[\e[0m\]@\[\e[31;1m\]\h\[\e[0m\] \W\[\e[0m\]]#
|
||||
PS1=[\[\e[33;1m\]\t \[\e[31;1m\]\u\[\e[0m\]@\[\e[31;1m\]\h\[\e[0m\] \W\[\e[0m\]]#
|
||||
AWS_IAM_HOME=/opt/aws/apitools/iam
|
||||
HISTCONTROL=ignoredups
|
||||
SHLVL=1
|
||||
SUDO_COMMAND=/bin/bash
|
||||
HOME=/root
|
||||
HISTTIMEFORMAT=[%Y-%m-%d %H:%M:%S]
|
||||
HISTTIMEFORMAT=[%Y-%m-%d %H:%M:%S]
|
||||
OLDPWD=/tmp
|
||||
|
||||
Global vs. User Profiles
|
||||
|
|
|
|||
|
|
@ -106,7 +106,7 @@ Business Savvy
|
|||
|
||||
Supporting business needs.
|
||||
--------------------------
|
||||
We exist professionally to support the needs of the organization.
|
||||
We exist professionally to support the needs of the organization.
|
||||
|
||||
Developing the Trusted Advisor Relationship
|
||||
-------------------------------------------
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ For example:
|
|||
It is a reliable server which is close to the other servers Bob works on.
|
||||
On ``server1``, but starts a multiplexer. The multiplexer gives Bob a regular
|
||||
looking command prompt, and Bob continues his work.
|
||||
|
||||
|
||||
If Bob's internet connection drops, he can reconnect to ``server1``, and then
|
||||
re-attach to the multiplexer he started previously. His session is in the
|
||||
same state he left it before being disconnected, and he can continue his
|
||||
|
|
@ -188,7 +188,7 @@ If there is more than one session the output of ``tmux ls`` will look like this:
|
|||
.. code-block:: bash
|
||||
|
||||
0: 3 windows (created Fri Nov 30 18:32:37 2012) [80x38]
|
||||
4: 1 windows (created Sun Dec 2 17:44:15 2012) [150x39] (attached)
|
||||
4: 1 windows (created Sun Dec 2 17:44:15 2012) [150x39] (attached)
|
||||
|
||||
You will then have to select the right session with the ``-t`` command line switch:
|
||||
|
||||
|
|
@ -202,7 +202,7 @@ you should only see one tmux process per user per system.
|
|||
You should see the original session with the two shells again after
|
||||
running this command.
|
||||
|
||||
tmux configuration
|
||||
tmux configuration
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
``tmux`` is configured via a
|
||||
config file which is usually called :file:`.tmux.conf` that should live in
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user