Fix typos, grammar, and outdated references in deployment guides

en/identity-server/7.1.0/docs/deploy/backup-and-recovery-recommendations.md

@@ -4,7 +4,7 @@ WSO2 Identity Server does not persist data in the file systems or retain or gene
 
 ## What you should back up?
 
-WSO2 Identity server recommends you to back up the following:
+WSO2 Identity Server recommends that you back up the following:
 
 - **Database backups** :
     Back up of all the databases defined in `<IS_HOME>/repository/conf/deployment.toml`.

en/identity-server/7.1.0/docs/deploy/configure-hazelcast.md

@@ -19,7 +19,7 @@
 
 - **Hazelcast logging type**:
 
-    - This configuration sets the hazelcast logging type to log4j, which allows hazelcast logs to be written to the `wso2carbon.log` file.
+    - This configuration sets the hazelcast logging type to log4j2, which allows hazelcast logs to be written to the `wso2carbon.log` file.
 
 Once you enable advanced logs for hazelcast as explained above, update the configuration of `logger.com-hazelcast.level` in the `<IS_HOME>/repository/conf/log4j2.properties` file. For more information on logging, see [Monitor Logs]({{base_path}}/deploy/monitor/monitor-logs).
 
@@ -55,3 +55,3 @@
 
 Now the old access token will still be valid according to node A even though it is already revoked by node B until the access token cache object in node A expires.
 

en/identity-server/7.1.0/docs/deploy/configure-tls-termination.md

@@ -3,7 +3,7 @@
 When you have Carbon servers fronted by a load balancer, you have the option of terminating SSL for HTTPS requests. This means that the load balancer will decrypt incoming HTTPS messages and forward them to WSO2 Identity Server again with HTTPS using private or self-signed certificates. Also, make sure that the load balancer is configured with TLS termination and the Tomcat `RemoteIpValve` is enabled for Carbon servers.
 
 !!! note "Important"
-    In the past we recommended using HTTP for internal communication to save some CPU overhead on TLS. However, modern security-conscious deployments benefit from having TLS for the traffic even when it is in between private endpoints. Hence, using HTTP endpoints is no-longer recommended on WSO2 Identity Server.
+    In the past we recommended using HTTP for internal communication to save some CPU overhead on TLS. However, modern security-conscious deployments benefit from having TLS for the traffic even when it is in between private endpoints. Hence, using HTTP endpoints is no longer recommended on WSO2 Identity Server.
 
 ## Step 1: Configure the load balancer with TLS termination
 
@@ -22,3 +22,3 @@
 remoteIpHeader ="x-forwarded-for"
 proxiesHeader="x-forwarded-by"
 trustedProxies="proxy1|proxy2"

en/identity-server/7.1.0/docs/deploy/front-with-the-nginx-load-balancer.md

@@ -14,13 +14,13 @@
 
 ![Deployment with the loadbalancer]({{base_path}}/assets/img/setup/deploy/deployment-with-the-loadbalancer.png)
 
 
 ## Configure Nginx
 
 Use the following steps to configure [NGINX Plus](https://www.nginx.com/products/){:target="_blank"} version 1.7.11 or [nginx community](http://nginx.org/){:target="_blank"} version 1.9.2 as the load balancer for WSO2 products. (In these steps, we refer to both versions collectively as "Nginx".)
 
 1. Install Nginx (NGINX Plus or Nginx community) in a server configured in your cluster.
-2. Configure Nginx to direct the HTTP requests to the two worker nodes via the HTTP 80 port using the `http://is.wso2.com/>`. To do this, create a VHost file ( ` is.http.conf ` ) in the `/etc/nginx/conf.d` directory and add the following configurations into it.
+2. Configure Nginx to direct the HTTP requests to the two worker nodes via the HTTP 80 port using `http://is.wso2.com/`. To do this, create a VHost file ( ` is.http.conf ` ) in the `/etc/nginx/conf.d` directory and add the following configurations into it.
 
     !!! note
          For NGINX Open Source, the location depends on the installation method and OS. Common locations include `/usr/local/nginx/conf`, `/etc/nginx`, or `/usr/local/etc/nginx`.
@@ -236,12 +236,12 @@
 
 5. Reload the Nginx server using the following command:
 
     ```
     $sudo service nginx reload
     ```
 
     !!! tip
         If you have made modifications to anything other than the VHost files, you may need to restart the Nginx server instead of reloading it.
         ```
         $sudo service nginx restart
         ```

en/identity-server/7.1.0/docs/deploy/token-persistence.md

@@ -16,7 +16,7 @@
 4. Alternatively, if an existing access token is not found, the OAuth2 component creates a new access token and persists it in the database using the same thread. Once it is persisted, the new token is returned to the client.
 
 !!! note "Synchronous token persistence configurations"
-    By default synchronous token persistence is enabled in WSO2 Identity Server 5.9.0 onwards. To indicate the number of times to retry in the event of a `CONN_APP_KEY` violation when storing the access token, navigate to file `<IS_HOME>/repository/conf/deployment.toml` and add the following configuration.
+    By default, synchronous token persistence is enabled in WSO2 Identity Server 5.9.0 onwards. To indicate the number of times to retry in the event of a `CONN_APP_KEY` violation when storing the access token, navigate to file `<IS_HOME>/repository/conf/deployment.toml` and add the following configuration.
 
     ```
     [oauth.token_generation]
@@ -46,7 +46,7 @@
 
 The above scenario is unlikely because in practice, an application is usually designed to handle this situation using scopes, or in the case of a multithreaded client, there is usually a separate thread to acquire access tokens so that other threads can retrieve from it.
 
 ### Synchronous token persistence
 
 The flow of the synchronous token persistence when receiving two identical access token requests is as follows: