Fixed smaller typos

for better SiteImprove results

Author: chabowski

adoc/CloudLS_Architecture.adoc

@@ -428,7 +428,7 @@ namely:
 
 - *Load balancing*: All OpenStack services that users and 
   other components themselves are using are HTTP(S) interfaces based
-  on the ReST principle. In large environments, they are
+  on the REST principle. In large environments, they are
   subject to a lot of load. In large-scale setups, it is required
   to use load balancers in front of the API instances to distribute the
   incoming requests evenly. This holds also true for MySQL (RabbitMQ however
@@ -600,7 +600,7 @@ installed and assigned to it. Four major roles exist:
 
 - *Management Nodes*: To run additional services such as Prometheus (a
   time-series database for monitoring, alerting and trending) and the ELK
-  stack (ElasticSearch, Logstash, Kibana - a log collection and index
+  stack (Elasticsearch, Logstash, Kibana - a log collection and index
   engine), further hardware is required. At least three machines per
   failure domain should be made available for this purpose.
 

adoc/CloudLS_Intro.adoc

@@ -147,7 +147,7 @@ Some of the key features of the OpenStack cloud computing software are as follow
 
 The SUSE OpenStack Cloud product is based on the upstream OpenStack project. It enables the 
 operator to smoothly deal with the complexity of the project and control the deployment, the daily operation and 
-the maintenace of the platform. The integrated deployment tool allows for an easy setup and deployment of
+the maintenance of the platform. The integrated deployment tool allows for an easy setup and deployment of
 the complex infrastructure. The professional support provided by SUSE ensures the provision of a stable and available platform,
 turning an open source project in an enterprise grade software solution.
 

adoc/CloudLS_Operations.adoc

@@ -337,12 +337,12 @@ anymore.
 ==== Variant 1: ELK
 
 A variant to create centralized logging based on open source
-software is the _ELK_ stack. ELK is an acronym for _ElasticSearch_, 
+software is the _ELK_ stack. ELK is an acronym for _Elasticsearch_, 
 _Logstash_ and _Kibana_ and refers to three components that are deployed 
-together. ElasticSearch is the indexing and search engine that received log 
+together. Elasticsearch is the indexing and search engine that received log 
 entries from systems. Logstash collects the log files from the target systems 
-and sends them to ElasticSearch. Kibana is a concise and easy-to-use interface 
-to Logstash and ElasticSearch and allows for web-based access.
+and sends them to Elasticsearch. Kibana is a concise and easy-to-use interface 
+to Logstash and Elasticsearch and allows for Web-based access.
 
 Although these three components are not always combined, the acronym _ELK_ 
 has become an established term for this solution. Sometimes, for example the

adoc/CloudLS_SDN.adoc

@@ -201,7 +201,7 @@ At a certain point in time, even the traffic passing between virtual machines
 in virtual networks must cross the physical borders between two systems. 
 Virtual traffic usually uses the management network, but to ensure that 
 management traffic of the platform and traffic from virtual networks do not 
-mix up, all available SDN solutions use some sort of encapsulation. VxLAN and 
+mix up, all available SDN solutions use some sort of encapsulation. VXLAN and 
 GRE tunnels are the most common choices (both terms refer to specific 
 technologies). Both technologies allow for the assignment of certain IT tags 
 to individual network packets. Traffic can easily be identified as 
@@ -286,7 +286,7 @@ by _neutron_, the Networking service of OpenStack.
 
 ==== Neutron Primer
 
-Neutron is a service that offers a ReSTful API and a plugin mechanism that
+Neutron is a service that offers a RESTful API and a plugin mechanism that
 allows to load plugins for a large number of SDN implementations. In
 certain setups, SDN solutions can be combined. However, combining SDN
 solutions is a complex task and should be accompanied by expert support.
@@ -307,7 +307,7 @@ requires multiple components on different target systems to work together
 properly. As an example, when a host boots up, the virtual
 switch for SDN on it must be configured at boot time. When a new VM is
 started on said host, a virtual port on the local virtual switch must be
-created and tagged with the correct settings for VxLAN or GRE. The VM
+created and tagged with the correct settings for VXLAN or GRE. The VM
 needs the network information (IP, DNS, Routing) and additional metadata
 to configure itself. 
 
@@ -320,7 +320,7 @@ agents are running on the network or compute nodes.
 Building SDN for OpenStack environments follows the basic design tenets 
 laid out earlier in this chapter. A typical SDN environment deployed as 
 part of SUSE OpenStack Cloud uses Open vSwitch to create the virtual 
-or _overlay_ network segment and VxLAN or GRE encapsulation to encapsulate 
+or _overlay_ network segment and VXLAN or GRE encapsulation to encapsulate 
 traffic on the _underlay_ level of the physical network, acting as
 management network.
 

adoc/CloudLS_SDS.adoc

@@ -157,9 +157,9 @@ need for ephemeral VM storage is served using the local space
 on the compute nodes.
 
 In addition to these two storage types, clouds offer an object storage 
-service that allows for access via the ReSTful protocol, which is based 
+service that allows for access via the RESTful protocol, which is based 
 on HTTP(S). Amazon S3 is the best-known type of implementation for such 
-a service. Users upload their asset data using the ReST protocol and can 
+a service. Users upload their asset data using the REST protocol and can 
 access them later from anywhere in the world.
 
 This kind of storage is often used as replacement for central asset
@@ -449,7 +449,7 @@ kernel driver. This allows for enhanced performance.
 ==== Ceph Front-Ends: Amazon S3 and OpenStack Swift
 
 The third Ceph front-end refers to the other type of storage that clouds 
-are expected to provide, which is object storage via a ReSTful protocol. 
+are expected to provide, which is object storage via a RESTful protocol. 
 Amazon Simple Storage Service (Amazon S3) is the most common service 
 of its kind. OpenStack also has a solution for storing objects and making 
 them accessible via an HTTPs protocol named _OpenStack swift_. 
@@ -500,7 +500,7 @@ CephFS, the POSIX-compatible file system in Ceph, can act here as back-end
 for manila.
 
 Finally, Ceph with the Ceph Object Gateway can act as a drop-in replacement 
-for swift, the ReSTful object storage for asset data. The Ceph 
+for swift, the RESTful object storage for asset data. The Ceph 
 Object Gateway even supports authentication using
 the OpenStack Identity service _keystone_, so that administering the
 users allowed to access Ceph's Swift back-end happens using the OpenStack

adoc/SLES4SAP-HANAonKVM-15SP2.adoc

@@ -494,7 +494,7 @@ To double check that only the desired C-states are actually available, the follo
 cpupower idle-info
 ----
 
-The idle state settings can be verified by looking at the line containing`Available idle states:`.
+The idle state settings can be verified by looking at the line containing `Available idle states:`.
 
 
 [[_sec_irqbalance]]

adoc/SLES4SAP-hana-scaleOut-PerfOpt-15.adoc

@@ -328,7 +328,7 @@ status* reflects this (return code 1). This happens when worker nodes are going
 down without any {HANA} standby nodes left. Standby nodes are designed to
 perform a host auto-failover for the worker functionality.
 Find more details on concept and implementation in manual page
-SAPHanaSR-ScaelOut(7).
+SAPHanaSR-ScaleOut(7).
 
 Without any additional intervention the resource agent will wait for the {sap}
 internal HA cluster to repair the situation locally. An additional intervention

adoc/SLES4SAP-sap-infra-monitoring-loki.adoc

@@ -85,7 +85,7 @@ Depending on the given directory path in our example above, the rule file has to
 
  /etc/loki/rules/fake/rules.yml
 
-NOTE: We are using `auth_enabled: false` and therefor the default tenant ID is `fake` which needs to be add
+NOTE: We are using `auth_enabled: false` and therefore the default tenant ID is `fake` which needs to be add
       to the path the rules are stored.
 
 The example rule below will trigger a mail (vial alertmanager configuration) if the password failed after accessing via ssh.

adoc/SLES4SAP-sap-infra-monitoring-nodeexporter.adoc

@@ -231,7 +231,7 @@ amcli_disk_information_summary{name="32/13", vendor="TOSHIBA", product="MBF2300R
 amcli_disk_information_summary{name="32/12", vendor="TOSHIBA", product="MBF2300RC", port_number="4", rotational_speed="10Krpm", power_status="Active", slot="7", status="Operational", ts="1646052400" } 1
 ----
 
-And the view from the node_exporter webui:
+And the view from the node_exporter WebUI:
 
 image::amcli-disk-info.png[amCLI disk information, collected from `amCLI` and sorted by `awk`,scaledwidth=100%,title="amCLI basic disk information"]
 

adoc/SLES4SAP-sap-infra-monitoring-prometheus.adoc

@@ -88,7 +88,7 @@ drwx------ 9 prometheus prometheus 199 Nov 18 18:00 /var/lib/prometheus
 ===== Prometheus configuration `prometheus.yml`
 Edit the Prometheus configuration file `/etc/prometheus/prometheus.yml` to include the scrape job configurations you want to add.
 In our example we have defined multiple job for different exporters. This would simplify the
-Grafana dashboard creation later and the Prometheus alertmanger rule definition.
+Grafana dashboard creation later and the Prometheus Alertmanager rule definition.
 
 [source]
 .Job definition for Node Exporter