Update ru.md

translations/ru.md

@@ -1070,49 +1070,49 @@ EFS
 -	🔸⏱  Операции с метаданными могут быть дорогостоящими с точки зрения массового потребления кредитов. При рекурсивном обходе дерева, содержащего тысячи файлов, можно легко увеличить потребление десятков или даже сотен мегабайт кредитов, даже если к файлам не притронулись. Команды типа ```find``` или ```chown -R``` могут оказать негативное влияние на производительность.
 
 
-Load Balancers
+Балансировщики нагрузки(Load Balancers)
 --------------
 
-### Load Balancer Basics
+### Основы Load Balancer
 
--	AWS has 3 load balancing products - “Classic Load Balancers” (CLBs), “Application Load Balancers” (ALBs), and "Network Load Balancers" (NLB).
--	Before the introduction of ALBs, “Classic Load Balancers” were known as “Elastic Load Balancers” (ELBs), so older documentation, tooling, and blog posts may still reference “ELBs”.
--	CLBs have been around since 2009, ALBs in 2016, NLBs were added in 2017 to AWS.
--	CLBs support TCP and HTTP load balancing. ALBs support HTTP load balancing only. NLBs support TCP layer 4 load balancing.
--	CLBs and ALBs can optionally handle termination for a single SSL certificate.
--	All can optionally perform active health checks of instances and remove them from the destination pool if they become unhealthy.
--	CLBs don't support complex / rule-based routing. ALBs support a (currently small) set of rule-based routing features. NLBs have most extensive routing options.
--	CLBs can only forward traffic to a single globally configured port on destination instances, while ALBs can forward to ports that are configured on a per-instance basis, better supporting routing to services on shared clusters with dynamic port assignment (like ECS or Mesos). NLBs support multiple ports on same IP; registering targets by IP address, including targets outside the VPC for the load balancer; ECS can select unused port for scheduling a task then register a target group using this port.
--	CLBs are supported in EC2 Classic as well as in VPCs while ALBs are supported in VPCs only.
--   ALBs can target groups of instances and IP based targets in the RFC1918 ranges allowing you to use on premise destinations via VPN or Direct Connect.
+-	AWS предлагает три продукта в области балансировки нагрузки - “Классические балансировщики нагрузки(Classic Load Balancers)” (CLBs), “Программные балансировщики нагрузки(Application Load Balancers)” (ALBs), и "Сетевые балансировщики нагрузки (Network Load Balancers)" (NLB).
+-	До появления ALB, “Классические балансировщики нагрузки” были известны, как “Эластичные балансировщики нагрузки(Elastic Load Balancers)” (ELBs), поэтому в более ранней документации, инструментах и публикациях в блогах все еще могут содержаться ссылки на “ELB”.
+-	CLB существуют с 2009 года, ALBs с 2016 года, NLBs были добавлены в AWS в 2017 году.
+-	CLB поддерживает балансировку нагрузки по TCP и HTTP. ALB поддерживает балансировку нагрузки только по HTTP. NLB поддерживает балансировку нагрузки по TCP на 4 уровне модели OSI.
+-	CLB и ALB может дополнительно терминировать SSL для одного сертификата SSL.
+-	Все они могут при необходимости выполнять активные проверки работоспособности инстансов и удалять их из пула назначения, если они стали не прошли проверку.
+-	CLB не поддерживает сложную, основанную на правилах, маршрутизацию. ALB поддерживает набор (на текущий момент не особо большой) вариантов маршрутизации, основанных на правилах. NLB предлагает самые широкие возможности маршрутизации.
+-	CLB может перенаправлять трафик только на один глобально настроенный порт в целевых инстансах, в то время как ALB может перенаправлять на порты, которые настроены для каждого инстанса, что лучше поддерживает маршрутизацию к службам в общих кластерах с динамическим назначением портов (например, ECS или Mesos). NLB поддерживает несколько портов на одном и том же IP-адресе; регистрацию целевых направлений по IP-адресам, включая целевые направления вне VPC, в котором находится балансировщик нагрузки; ECS может выбрать неиспользуемый порт для планирования таска, а затем зарегистрировать целевую группу, используя этот порт.
+-	CLB поддерживаются, как в EC2 Classic, так и в VPC, в то время как ALB поддерживаются только в VPC.
+-   ALB могут использовать в целевых группах группы инстансов и цели на основе IP в диапазонах RFC1918, что позволяет использовать их для направления траффика на локальные сервера через VPN или Direct Connect.
 
-### Load Balancer Tips
+### Советы по Load Balancer
 
--	If you don’t have opinions on your load balancing up front, and don’t have complex load balancing needs like application-specific routing of requests, it’s reasonable just to use a CLB or ALB for load balancing instead.
--	Even if you don’t want to think about load balancing at all, because your architecture is so simple (say, just one server), put a load balancer in front of it anyway. This gives you more flexibility when upgrading, since you won’t have to change any DNS settings that will be slow to propagate, and also it lets you do a few things like terminate SSL more easily.
--	**CLBs and ALBs have many IPs:** Internally, an AWS load balancer is simply a collection of individual software load balancers hosted within EC2, with DNS load balancing traffic among them. The pool can contain many IPs, at least one per availability zone, and depending on traffic levels. They also support SSL termination, which is very convenient.
--	**Scaling:** CLBs and ALBs can scale to very high throughput, but scaling up is not instantaneous. If you’re expecting to be hit with a lot of traffic suddenly, it can make sense to load test them so they scale up in advance. You can also [contact Amazon](http://aws.amazon.com/articles/1636185810492479) and have them “pre-warm” the load balancer.
--	**Client IPs:** In general, if servers want to know true client IP addresses, load balancers must forward this information somehow. CLBs add the standard [X-Forwarded-For](https://en.wikipedia.org/wiki/X-Forwarded-For) header. When using a CLB as an HTTP load balancer, it’s possible to get the client’s IP address from this.
--	**Using load balancers when deploying:** One common pattern is to swap instances in the load balancer after spinning up a new stack with your latest version, keep old stack running for one or two hours, and either flip back to old stack in case of problems or tear it down.
--   **Rotating Certificates while retaining ARN:** Rotating IAM Server Certificates can be difficult as the standard practice is to upload a new one then update all resources with the new ARN. You can however retain the same ARN using the `update-certificate` call with the following process:
-  1. Upload a new IAM Server Certificate with a unique name (e.g fuzzy.com.new)
-  2. Rename the existing IAM Server Certificate (e.g fuzzy.com to fuzzy.com.expired)
-  3. Rename the new IAM Server Certificate to the name of the previously existing certificate (e.g fuzzy.com.new to fuzzy.com)
-  4. Jiggle the CLB/ALB Listener to pick up the change:
-      * ALB: Invoke modify-listener with the existing details for the ALB Listener
-	  * CLB: Invoke create-load-balancer-listeners with the existing details for the CLB listener
+-	Если у вас заранее нет какого-либо мнения относительно балансировки нагрузки и нет сложных требований по балансировке нагрузки на основе специфичной для конкретного приложения маршрутизации запросов, разумным будет использовать CLB или ALB.
+-	Если вы не хотите вообще думать о балансировке нагрузки, так как ваша архитектура крайне проста (скажем, только один сервер), все равно стоит поставить балансировщик нагрузки перед ним. Это даст вам большую гибкость во время обновления, так как вам не придется менять никакие настройки DNS, которые довольно таки долго распространяются, а также позволит вам делать некоторые вещи, типа терминации SSL гораздо легче.
+-	**CLB и ALB могут иметь множество IP адресов:** Внутренне балансировщик нагрузки AWS - это просто набор отдельных программных балансировщиков нагрузки, размещенных в EC2, с распределением траффика путем балансировки нагрузки по DNS. Этот пул может содержать множество IP-адресов, как минимум по одному на каждую зону доступности и в зависимости от уровня нагрузки. Также они поддерживают терминацию SSL, что является очень удобным.
+-	**Масштабирование:** CLB и ALB могут масштабироваться до очень высокой пропускной способности, однако масштабирование не является мгновенным процессом. Если вы ожидаете внезапного появления большого количества трафика, имеет смысл создать тестовую нагрузку, чтобы они заранее масштабировались. Вы также можете [связаться с Amazon](http://aws.amazon.com/articles/1636185810492479) чтобы они “прогрели” балансировщик нагрузки.
+-	**Клиентские IP-адреса:** В общем, если серверы хотят знать истинные IP-адреса клиентов, балансировщики нагрузки должны каким-то образом пересылать эту информацию. CLB добавляет стандартный заголовок [X-Forwarded-For](https://en.wikipedia.org/wiki/X-Forwarded-For). При использовании CLB, как балансировщика нагрузки HTTP траффика, возможно таким образом получать клиентский IP-адрес.
+-	**Использование балансировщиков нагрузки при развертывании:** Один из распространенных шаблонов заключается в замене инстансов в балансировщике нагрузки после развертывания нового стека на последнюю версию, сохранения работоспособности старого стека в течение одного или двух часов и либо возврата к старому стеку в случае проблем, либо его сноса.
+-   **Замена сертификатов с сохранением ARN:** Замена серверных сертификатов IAM может быть сложной, так как стандартная практика - загрузить новый и обновить все ресурсы с новым ARN. В любом случае, вы можете сохранить тот же ARN используя вызов `update-certificate` следующим путем:
+  1. Загрузить новый сертификат IAM с уникальным именем (например, fuzzy.com.new)
+  2. Переименовать существующий сертификат (например, fuzzy.com в fuzzy.com.expired)
+  3. Переименовать новый сертификат IAM на имя прошлого существующего сертификата (например, fuzzy.com.new в fuzzy.com)
+  4. Передернуть CLB/ALB Listener чтобы подтянуть изменения:
+      * ALB: Вызовите modify-listener с существующими параметрами ALB Listener
+	  * CLB: Вызовите create-load-balancer-listeners с существующими параметрами CLB listener
 
-### Load Balancer Gotchas and Limitations
+### Ошибки и ограничения, связанные с Load Balancer 
 
--	❗CLBs and ALBs have **no fixed external IP** that all clients see. For most consumer apps this doesn’t matter, but enterprise customers of yours may want this. IPs will be different for each user, and will vary unpredictably for a single client over time (within the standard [EC2 IP ranges](http://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html)). And similarly, never resolve a CLB name to an IP and put it as the value of an A record — it will work for a while, then break!
--	❗Some web clients or reverse proxies cache DNS lookups for a long time, which is problematic for CLBs and ALBs, since they change their IPs. This means after a few minutes, hours, or days, your client will stop working, unless you disable DNS caching. Watch out for [Java’s settings](http://docs.oracle.com/javase/8/docs/api/java/net/InetAddress.html) and be sure to [adjust them properly](http://docs.aws.amazon.com/AWSSdkDocsJava/latest/DeveloperGuide/java-dg-jvm-ttl.html). Another example is nginx as a reverse proxy, which [normally resolves backends only at start-up](https://www.jethrocarr.com/2013/11/02/nginx-reverse-proxies-and-dns-resolution/) (although there is [a way to get around this](https://tenzer.dk/nginx-with-dynamic-upstreams/)).
--	❗It’s not unheard of for IPs to be recycled between customers without a long cool-off period. So as a client, if you cache an IP and are not using SSL (to verify the server), you might get not just errors, but responses from completely different services or companies!
--	🔸As an operator of a service behind a CLB or ALB, the latter phenomenon means you can also see puzzling or erroneous requests by clients of other companies. This is most common with clients using back-end APIs (since web browsers typically cache for a limited period).
--	❗CLBs and ALBs take time to scale up, it does not handle sudden spikes in traffic well. Therefore, if you anticipate a spike, you need to “pre-warm” the load balancer by gradually sending an increasing amount of traffic.
--	❗Tune your healthchecks carefully — if you are too aggressive about deciding when to remove an instance and conservative about adding it back into the pool, the service that your load balancer is fronting may become inaccessible for seconds or minutes at a time. Be extra careful about this when an autoscaler is configured to terminate instances that are marked as being unhealthy by a managed load balancer.
--	❗CLB HTTPS listeners don't support Server Name Indication (SNI). If you need SNI, you can work around this limitation by either providing a certificate with Subject Alternative Names (SANs) or by using TCP listeners and terminating SSL at your backend.
--	🔸 There is a limit on the number of ALBs, CLBs and NLBs per region (separately). As of late 2017, the default limit for each is 20 per region. These limits can be easily raised for ALB and CLB, but AWS is quite reluctant to raise the limit on NLBs.
--	🔸 If using a Network Load Balancer (NLB) then EC2 clients cannot connect to an NLB that resides in another VPC (VPC Peering) or AWS managed VPN unless the EC2 client is a C5, i3.metal or M5 instance type. For VPC peering, both VPCs must be in the same region. See [Troubleshooting](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-troubleshooting.html#target-not-in-service).
+-	❗CLB и ALBs не имеют **фиксированных публичных IP-адресов**, которые видны клиентам. Для большинства пользовательских приложений это не имеет значения, но ваши корпоративные клиенты могут этого захотеть. IP-адреса будут отличаться для каждого пользователя и непредсказуемо изменяться для одного клиента с течением времени (в пределах стандартных [диапазонов IP-адресов EC2](http://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html)). И точно так же никогда не резолвите имя CLB в IP и не указывайте его в качестве значения записи A - оно будет работать некоторое время, а затем сломается!
+-	❗Некоторые веб-клиенты или обратные прокси-серверы кешируют DNS-запросы в течение длительного времени, что создает проблему для CLB и ALB, поскольку они меняют свои IP-адреса. Это означает, что через несколько минут, часов или дней, ваши клиенты перестанут работать, пока вы не отключите кэширование DNS. Следите за [настройками Java](http://docs.oracle.com/javase/8/docs/api/java/net/InetAddress.html) и обязательно [настройте их правильно](http://docs.aws.amazon.com/AWSSdkDocsJava/latest/DeveloperGuide/java-dg-jvm-ttl.html). Другим примером может быть использование nginx в роли обратного прокси-сервера, который [обычно резолвит бэкенды только при запуске](https://www.jethrocarr.com/2013/11/02/nginx-reverse-proxies-and-dns-resolution/) (хотя есть [способ обойти эту проблему](https://tenzer.dk/nginx-with-dynamic-upstreams/)).
+-	❗Пускай для вас не будет неожиданным, что IP-адреса будут перераспределяться между клиентами без длительного отстоя в пуле свободных адресов. Поэтому, как клиент, если вы кешируете IP-адрес и не используете SSL (для проверки сервера), вы можете получить не просто ошибки, а ответы от совершенно разных служб или компаний!
+-	🔸Как оператор службы, работающей за CLB или ALB, последнее явление означает, что вы также можете видеть странные или ошибочные запросы клиентов других компаний. Это наиболее часто встречается у клиентов, использующих серверные API-интерфейсы (поскольку веб-браузеры обычно кешируют в течение ограниченного периода времени).
+-	❗CLB и ALB требуется время для масштабирования, они не вытягивают внезапные всплески траффика. Таким образом, если вы ожидаете всплеск, вам необходимо “прогреть” балансировщик нагрузски постепенно посылая на него повышающиеся объемы траффика.
+-	❗Тщательно настройте проверку работоспособности - если вы слишком агрессивны в отношении решения о том, когда удалять инстанс, и консервативны в отношении добавления его обратно в пул, служба, которую обслуживает ваш балансировщик нагрузки, может стать недоступной на несколько секунд или минут. Будьте крайне осторожны с этим, когда автоматическое масштабирование настроено на удаление инстансов, которые не прошли проверку балансировщика нагрузки.
+-	❗CLB HTTPS listeners не поддерживают Индикацию имени сервера(Server Name Indication) (SNI). Если вам нужен SNI, вы можете обойти это ограничение используя сертификат с Subject Alternative Names (SAN) или используя TCP listener и терминируя SSL на бэкенде.
+-	🔸 Существует ограничение на количество ALB, CLB и NLB на регион (отдельное для каждого). На конец 2017 года, ограничение по умолчанию для каждого - 20 на регион. Эти лимиты могут быть лекго повышены для ALB и CLB, но AWS довольно неохотно поднимает лимит для NLB.
+-	🔸 Если вы используете сетевой балансировщик нагрузки(NLB) тогда клиенты EC2 не смогут подключиться к NLB, который находится в другом VPC (пиринг VPC) или VPN под управлением AWS, если только клиент EC2 не является экземпляром C5, i3.metal или M5. Для пиринга VPC оба VPC должны быть в одном и том же регионе. Тут описано [устранение неполадок](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-troubleshooting.html#target-not-in-service).
 
 Классический балансировщик нагрузки(CLB)
 ---