Приветствую,
планируем в компании разработку сайта и одним из требования высокая нагрузка (посещаемость 30к+ пользователей в пике 50к — 70к).
вопрос платформы сразу был определен — Java (Spring Boot, Spring MVC, JPA+hibernate, ehcache), AngularJs
с базой данных так же более менее ясно (MySQL or Postgress), вот только реплицировать ли её...
Но что-то мне подсказывает такой нагрузки держать не будет сайт (хоть сайт и простой по функциональности, регистрация/авторизация/просмотр статей, отправка/прием сообщений)...
И почитав статьи, стало быть люди пишут про некоторые архитектуры, которые используют несколько инстанцев на которые перенаправляет лоад-балансер.
Но толи статьи плохие попадались, либо это все так неоднозначно, ни каких конкретных архитектур ненашел, одна "вода".
1. Может кто подскажет матерьял для изучения или хорошую статью!?
2. Совсем не ясно какие бывают лоадбалансеры?, как настраиваются? (попадался только ngnix, но о настрайках ничего конкретного)
3. И что с Базой Данных, реплицировать её ли, если да, то как с ней после работать...
4. И с какими неожиданными моментами можно сталкнуться (чего ожидать)?
Вообщем есть пробелы в понимании выше описанных вещей, если кто сталкивался буду очень рад помощи — наставления на путь истенный.
Здравствуйте, garryg, Вы писали:
G>планируем в компании разработку сайта и одним из требования высокая нагрузка (посещаемость 30к+ пользователей в пике 50к — 70к).
А что означает эта цифра? Надо исходить из числа запросов. На новостной сайт посетитель может делать запрос раз в 5 минут. В каком-нибудь онлайн-покере раз в секунду, а то и чаще.
G>вопрос платформы сразу был определен — Java (Spring Boot, Spring MVC, JPA+hibernate, ehcache), AngularJs G>с базой данных так же более менее ясно (MySQL or Postgress), вот только реплицировать ли её...
Ну на чтение реплицировать обычно несложно. Вот если упрётесь в предел по записи, будет тяжело. Но у вас же JPA + ehcache, зачем вам масштабировать базу? Настройте грамотно кеш и будет счастье.
G>Но что-то мне подсказывает такой нагрузки держать не будет сайт (хоть сайт и простой по функциональности, регистрация/авторизация/просмотр статей, отправка/прием сообщений)...
Вообще говоря современный сервер средней руки (пара современных Xeon-ов по 8 ядер, 64 GB RAM, SSD-raid) способен выдержать на таком функционале, думаю, порядка 10000 запросов в секунду, если реализация будет хорошая. Этого хватит, даже если весь мир ломанётся читать ваш сайт. А кеширование от cloudflare даст ещё больший запас по прочности.
G>И почитав статьи, стало быть люди пишут про некоторые архитектуры, которые используют несколько инстанцев на которые перенаправляет лоад-балансер. G>Но толи статьи плохие попадались, либо это все так неоднозначно, ни каких конкретных архитектур ненашел, одна "вода".
G>1. Может кто подскажет матерьял для изучения или хорошую статью!? G>2. Совсем не ясно какие бывают лоадбалансеры?, как настраиваются? (попадался только ngnix, но о настрайках ничего конкретного) G>3. И что с Базой Данных, реплицировать её ли, если да, то как с ней после работать... G>4. И с какими неожиданными моментами можно сталкнуться (чего ожидать)?
G>Вообщем есть пробелы в понимании выше описанных вещей, если кто сталкивался буду очень рад помощи — наставления на путь истенный.
Ставите кучку серверов с томкатом в каждом. Ставите один сервер с nginx-ом, настраиваете там распределение запросов по серверам. Если в сессии ничего не хранить кроме аутентификационных данных, то сессию можно не реплицировать и на nginx-е настроить, чтобы он по JSESSIONID выбирал бэкэнд, на который надо направлять запрос. Все мануалы по настройке есть в сети.
Базу реплицировать легко на чтение (в одну базу идёт запись, данные от неё раскидываются по read-only копиям). На запись традиционные БД реплицировать прозрачно для приложения сложно. Обычно распределяют данные по какому-нибудь естественному признаку (например по стране) и раскладывают в разные базы. Но это достаточно сложная логика.
Моё имхо, не нужен вам кластер. Хороший физический сервер, без всяких виртуалок ставите туда базу, туда же томкат (чтобы байты по сети не гонять безтолку) и всё будет быстро работать.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, garryg, Вы писали:
G>>планируем в компании разработку сайта и одним из требования высокая нагрузка (посещаемость 30к+ пользователей в пике 50к — 70к).
vsb>А что означает эта цифра? Надо исходить из числа запросов. На новостной сайт посетитель может делать запрос раз в 5 минут. В каком-нибудь онлайн-покере раз в секунду, а то и чаще.
расчитываем на 30000 запросов в секунду. Сайт не новостной, типа блогинга + обмен сообщениями.
G>>вопрос платформы сразу был определен — Java (Spring Boot, Spring MVC, JPA+hibernate, ehcache), AngularJs G>>с базой данных так же более менее ясно (MySQL or Postgress), вот только реплицировать ли её...
vsb>Ну на чтение реплицировать обычно несложно. Вот если упрётесь в предел по записи, будет тяжело. Но у вас же JPA + ehcache, зачем вам масштабировать базу? Настройте грамотно кеш и будет счастье.
Это да, но как быть с транзакционностью в такой репликации!?
G>>Но что-то мне подсказывает такой нагрузки держать не будет сайт (хоть сайт и простой по функциональности, регистрация/авторизация/просмотр статей, отправка/прием сообщений)...
vsb>Вообще говоря современный сервер средней руки (пара современных Xeon-ов по 8 ядер, 64 GB RAM, SSD-raid) способен выдержать на таком функционале, думаю, порядка 10000 запросов в секунду, если реализация будет хорошая. Этого хватит, даже если весь мир ломанётся читать ваш сайт. А кеширование от cloudflare даст ещё больший запас по прочности.
боюсь как бы GC не стал затыкаться при такой апликухи на серваке...
G>>И почитав статьи, стало быть люди пишут про некоторые архитектуры, которые используют несколько инстанцев на которые перенаправляет лоад-балансер. G>>Но толи статьи плохие попадались, либо это все так неоднозначно, ни каких конкретных архитектур ненашел, одна "вода".
G>>1. Может кто подскажет матерьял для изучения или хорошую статью!? G>>2. Совсем не ясно какие бывают лоадбалансеры?, как настраиваются? (попадался только ngnix, но о настрайках ничего конкретного) G>>3. И что с Базой Данных, реплицировать её ли, если да, то как с ней после работать... G>>4. И с какими неожиданными моментами можно сталкнуться (чего ожидать)?
G>>Вообщем есть пробелы в понимании выше описанных вещей, если кто сталкивался буду очень рад помощи — наставления на путь истенный.
vsb>Ставите кучку серверов с томкатом в каждом. Ставите один сервер с nginx-ом, настраиваете там распределение запросов по серверам. Если в сессии ничего не хранить кроме аутентификационных данных, то сессию можно не реплицировать и на nginx-е настроить, чтобы он по JSESSIONID выбирал бэкэнд, на который надо направлять запрос. Все мануалы по настройке есть в сети.
вот мысли были об этом
на практике не делал такого?
vsb>Базу реплицировать легко на чтение (в одну базу идёт запись, данные от неё раскидываются по read-only копиям). На запись традиционные БД реплицировать прозрачно для приложения сложно. Обычно распределяют данные по какому-нибудь естественному признаку (например по стране) и раскладывают в разные базы. Но это достаточно сложная логика.
vsb>Моё имхо, не нужен вам кластер. Хороший физический сервер, без всяких виртуалок ставите туда базу, туда же томкат (чтобы байты по сети не гонять безтолку) и всё будет быстро работать.
томкат это хорошо, но в качестве контейнера думал о GlassFish либо WildFly — что скажешь?
G>расчитываем на 30000 запросов в секунду. Сайт не новостной, типа блогинга + обмен сообщениями.
В качестве БД на _запись_, советую Cassandra, быстрее нее, формально ничего нет, т.к. она пишет данные последовательно на диск.
Master — Master репликация, избыточное хранение — из коробки, линейный рост производительности при добавлении железа. Если правильно уложены данные, то чтение тоже мгновенное, т.к. она их считывает так же последовательно.
Надежность 100%, в одной конторе работает без меня уже третий год — боятся даже к серверам подходить
Так же можно использовать для хранения сессий, т.к. и репликация и быстро и не ограничен размером RAM.
Читал, что люди отказывались от отдельных кешей, т.к. Cassandra сам с этим отлично справляется.
А впереди Round robin DNS
Интересно было-бы поучаствовать в нагрузочном тестировании, так что если что, зови (panov.andy gmail.com)
Здравствуйте, garryg, Вы писали:
G>с базой данных так же более менее ясно (MySQL or Postgress), вот только реплицировать ли её...
Для массивных апдейтов Postgress лучше. Так как он версионнник, там конкуренция разруливатся лучше. Но это оффтоп. MySQL классно использовать в NoSQL стиле.
G>1. Может кто подскажет матерьял для изучения или хорошую статью!?
Мне в своё время вот эта статья очень помогла разобраться http://www.theserverside.com/news/1364410/Under-the-Hood-of-J2EE-Clustering
G>2. Совсем не ясно какие бывают лоадбалансеры?, как настраиваются? (попадался только ngnix, но о настрайках ничего конкретного)
Разные бывают. Лучше гуглить не о самих балансерах, а о принципах балансировки. Когда будет понимание принципов работы и нужных терминов, найти настройки под конкретный сервер будет проще.
Разберись, например с тем что такое Round Robin и Sticky Sessions.
G>3. И что с Базой Данных, реплицировать её ли, если да, то как с ней после работать...
Ну, это отдельный вопрос. При хорошей распределенной нагрузке на Java можно минимизировать работу с БД, так что и одного экземпляра хватит с головой.
Вычислять состояния все в памяти Java, а в БД только переодически сохранять snapshot-ы, например. Опять же, сложно дать конкретику не зная предметной области и требований.
Либо Master-Slave репликации применить, когда запросов много, а апдейтов намного меньше. Решений много. Надо найти DBA и обсудить с ним специфику.
G>4. И с какими неожиданными моментами можно сталкнуться (чего ожидать)?
Брр. Да, с любыми. Необходимость оптимизации GC. Планирование failover. Распраделение нагрузки (падает одна нода кластера, юзеры раскидываются по всем остальным нодам и те тоже падают от перегрузки). Масса всего.
G>Вообщем есть пробелы в понимании выше описанных вещей, если кто сталкивался буду очень рад помощи — наставления на путь истенный.
Статьи надо читать. Изучать архитектуру существующих решений — Facebook, Одноклассники, LMAX. Смотреть презентации и доклады про highload. https://www.youtube.com/watch?v=Q-7y1u9kZV0
G>>расчитываем на 30000 запросов в секунду. Сайт не новостной, типа блогинга + обмен сообщениями. B>В качестве БД на _запись_, советую Cassandra, быстрее нее, формально ничего нет, т.к. она пишет данные последовательно на диск.
Много о Cassandra слышал и восновном хорошее , посматривал в её сторону, но никогда не щупал...
но менять модель реляционной ДБ на не реляционную — надо прикинуть
B>Master — Master репликация, избыточное хранение — из коробки, линейный рост производительности при добавлении железа. Если правильно уложены данные, то чтение тоже мгновенное, т.к. она их считывает так же последовательно. B>Надежность 100%, в одной конторе работает без меня уже третий год — боятся даже к серверам подходить B>Так же можно использовать для хранения сессий, т.к. и репликация и быстро и не ограничен размером RAM.
B>Читал, что люди отказывались от отдельных кешей, т.к. Cassandra сам с этим отлично справляется.
B>А впереди Round robin DNS
Вот это уже интереснее!
B>Интересно было-бы поучаствовать в нагрузочном тестировании, так что если что, зови (panov.andy gmail.com)
Буду только рад! отправил письмо.
On 13.02.2015 00:47, garryg wrote:
> vsb>Ставите кучку серверов с томкатом в каждом. Ставите один сервер с > nginx-ом, настраиваете там распределение запросов по серверам. Если в > сессии ничего не хранить кроме аутентификационных данных, то сессию > можно не реплицировать и на nginx-е настроить, чтобы он по JSESSIONID > выбирал бэкэнд, на который надо направлять запрос.
Тут немного не так. Если сессии есть вообще, то нужен выбор между sticky
sessions (не реплицируются, привязываются на nginx по jsessionid) и их
репликацией. А хранятся в них только аутентификация или какие-либо
данные ещё — это не так принципиально. Нельзя хранить в сессиях тяжёлые
объекты, ну и конечно всякие несериализуемые вещи типа открытых
Connection ))) (видел один раз такое).
Все мануалы по > настройке есть в сети. > > вот мысли были об этом > на практике не делал такого?
Я делал такое, не один раз (на платформах jboss и weblogic). Ничего
сложного вообще. Главное в этой теме — понимание что такое JEE
clustering (из каких частей состоит) и внимательное чтение док к
конкретному аппсерверу. Ну и перфоманс тесты, без них никуда.
Кстати есть небольшая засада — sticky sessions доступны только в платной
версии nginx, но это обходится, т.к. есть свободно распространяемый
модуль к нему, который, правда, придётся собрать из исходников.
> томкат это хорошо, но в качестве контейнера думал о GlassFish либо > WildFly — что скажешь?
Посоветовал бы посмотреть на JBoss EAP. Для такого высоконагруженного
проекта поддержка вендора будет совсем не лишней.
Здравствуйте, garryg, Вы писали:
G>томкат это хорошо, но в качестве контейнера думал о GlassFish либо WildFly — что скажешь?
GF — сразу нет. Количество багов на ровном месте в GF, как и в NB зашкаливает.
WildFly, как кровный родственник JBoss должен иметь сносную кластеризацию.
Здравствуйте, garryg, Вы писали:
vsb>>А что означает эта цифра? Надо исходить из числа запросов. На новостной сайт посетитель может делать запрос раз в 5 минут. В каком-нибудь онлайн-покере раз в секунду, а то и чаще.
G>расчитываем на 30000 запросов в секунду. Сайт не новостной, типа блогинга + обмен сообщениями.
Ну нагрузка неплохая, конечно, тут тогда выходит на первое место вопрос — сколько будет записей в БД.
vsb>>Ну на чтение реплицировать обычно несложно. Вот если упрётесь в предел по записи, будет тяжело. Но у вас же JPA + ehcache, зачем вам масштабировать базу? Настройте грамотно кеш и будет счастье. G>Это да, но как быть с транзакционностью в такой репликации!?
Надо исследовать вопрос. Есть транзакционные кеши для хибернейта. Есть не очень транзакционные. В любом случае там транзакционность будет на каком то уровне, имхо, достаточном для вашего случая.
G>боюсь как бы GC не стал затыкаться при такой апликухи на серваке...
Современный GC может останавливать мир на небольшое время, но по идее в целом это не должно сильно отражаться на функционировании. Будет раз в минуту стопать на десятую секунды. Если что, есть Azul, это JVM с неостанавливающим мир GC. Денег стоит, правда.
vsb>>Ставите кучку серверов с томкатом в каждом. Ставите один сервер с nginx-ом, настраиваете там распределение запросов по серверам. Если в сессии ничего не хранить кроме аутентификационных данных, то сессию можно не реплицировать и на nginx-е настроить, чтобы он по JSESSIONID выбирал бэкэнд, на который надо направлять запрос. Все мануалы по настройке есть в сети.
G>вот мысли были об этом G>на практике не делал такого?
Видел, сам не настраивал.
vsb>>Моё имхо, не нужен вам кластер. Хороший физический сервер, без всяких виртуалок ставите туда базу, туда же томкат (чтобы байты по сети не гонять безтолку) и всё будет быстро работать.
G>томкат это хорошо, но в качестве контейнера думал о GlassFish либо WildFly — что скажешь?
А там не тот же томкат внутрях? Если они лучше, можно и их. Раз Spring + Hibernate использовать собираетесь, JEE вроде ничего ценного не даст, будут просто лишние мегабайты на диске лежать. Можно хоть на Jetty стартовать, все эти HTTP стеки примерно одинаково устроены. Томкат я обычно ставлю "по дефолту" потому что привык и он даёт некие минимальные удобства (настройка через конфиги, старт-стоп, в винде можно сервис сделать), но это всё мелочи.
Здравствуйте, Blazkowicz, Вы писали:
G>>томкат это хорошо, но в качестве контейнера думал о GlassFish либо WildFly — что скажешь? B>GF — сразу нет. Количество багов на ровном месте в GF, как и в NB зашкаливает.
Вот поддержу про GF. Нас угораздило вляпатся в это, багов море. Кое как справились с 3.1.2.2 какие то баги обошли, с какими то смирились, все эти танцы заняли несусветное количество времени. Пробовали перейти на 4.x — начинай все по новой, то не работает, тут бага, не удался переход короче.
On 13.02.2015 12:06, GarryIV wrote:
> Вот поддержу про GF. Нас угораздило вляпатся в это, багов море. Кое как > справились с 3.1.2.2 какие то баги обошли, с какими то смирились, все > эти танцы заняли несусветное количество времени.
+100500
> Пробовали перейти на > 4.x — начинай все по новой, то не работает, тут бага, не удался переход > короче.
Даже не стали пробовать.
Здравствуйте, bosyak, Вы писали:
B>В качестве БД на _запись_, советую Cassandra, быстрее нее, формально ничего нет, т.к. она пишет данные последовательно на диск.
Пока категорически на готова для продакшена.
Падает просто так, клиент отваливается и не может ольше реконнектнуться, и т.д.
С уважением, Евгений
JetBrains, Inc. "Develop with pleasure!"
On 13.02.2015 11:16, Blazkowicz wrote:
> G>томкат это хорошо, но в качестве контейнера думал о GlassFish либо > WildFly — что скажешь? > GF — сразу нет. Количество багов на ровном месте в GF, как и в NB > зашкаливает.
Здравствуйте, hrensgory, Вы писали:
H>А NB — это кто?
NetBeans — ближайшая подружка GF. Каждый раз когда сталкиваюсь, наблюдаю баги на ровном месте. Вчера за пол-дня выхватил две баги и одну багофичу. Жесть, а не IDE.
On 13.02.2015 12:44, Blazkowicz wrote:
> H>А NB — это кто? > NetBeans — ближайшая подружка GF. Каждый раз когда сталкиваюсь, наблюдаю > баги на ровном месте. Вчера за пол-дня выхватил две баги и одну > багофичу. Жесть, а не IDE.
А, я думал какой-то аппсервер не разгадал, стал уж в уме всякую экзотику
перебирать вроде Apache Geronimo, Caucho Resin, Hitachi, Fujitsu и
т.п., а не подходит ни один )
Здравствуйте, garryg, Вы писали:
G>4. И с какими неожиданными моментами можно сталкнуться (чего ожидать)?
Про неожиданности, как раз сегодня встретил статейку: Providence: Failure Is Always an Option.
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, garryg, Вы писали:
G>>с базой данных так же более менее ясно (MySQL or Postgress), вот только реплицировать ли её... B>Для массивных апдейтов Postgress лучше. Так как он версионнник, там конкуренция разруливатся лучше. Но это оффтоп. MySQL классно использовать в NoSQL стиле.
Благодарю! Изучим.
G>>2. Совсем не ясно какие бывают лоадбалансеры?, как настраиваются? (попадался только ngnix, но о настрайках ничего конкретного) B>Разные бывают. Лучше гуглить не о самих балансерах, а о принципах балансировки. Когда будет понимание принципов работы и нужных терминов, найти настройки под конкретный сервер будет проще. B>Разберись, например с тем что такое Round Robin и Sticky Sessions.
G>>3. И что с Базой Данных, реплицировать её ли, если да, то как с ней после работать... B>Ну, это отдельный вопрос. При хорошей распределенной нагрузке на Java можно минимизировать работу с БД, так что и одного экземпляра хватит с головой. B>Вычислять состояния все в памяти Java, а в БД только переодически сохранять snapshot-ы, например. Опять же, сложно дать конкретику не зная предметной области и требований. B>Либо Master-Slave репликации применить, когда запросов много, а апдейтов намного меньше. Решений много. Надо найти DBA и обсудить с ним специфику.
Пожалуй лишним небудет сделать реплику, да же со стороны безопасноти данных (в случае краха базы).
G>>4. И с какими неожиданными моментами можно сталкнуться (чего ожидать)? B>Брр. Да, с любыми. Необходимость оптимизации GC. Планирование failover. Распраделение нагрузки (падает одна нода кластера, юзеры раскидываются по всем остальным нодам и те тоже падают от перегрузки). Масса всего.
Это да... но есть же какие-то часто встречаемые грабли!?
G>>Вообщем есть пробелы в понимании выше описанных вещей, если кто сталкивался буду очень рад помощи — наставления на путь истенный. B>Статьи надо читать. Изучать архитектуру существующих решений — Facebook, Одноклассники, LMAX. Смотреть презентации и доклады про highload. B>https://www.youtube.com/watch?v=Q-7y1u9kZV0
B>Ну, и больше загрядывать в профильные форумы, например B>http://rsdn.ru/forum/design
Большое спасибо за подробное пояснение, будем учить и вникать
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, garryg, Вы писали:
vsb>>>А что означает эта цифра? Надо исходить из числа запросов. На новостной сайт посетитель может делать запрос раз в 5 минут. В каком-нибудь онлайн-покере раз в секунду, а то и чаще.
G>>расчитываем на 30000 запросов в секунду. Сайт не новостной, типа блогинга + обмен сообщениями.
vsb>Ну нагрузка неплохая, конечно, тут тогда выходит на первое место вопрос — сколько будет записей в БД.
vsb>>>Ну на чтение реплицировать обычно несложно. Вот если упрётесь в предел по записи, будет тяжело. Но у вас же JPA + ehcache, зачем вам масштабировать базу? Настройте грамотно кеш и будет счастье. G>>Это да, но как быть с транзакционностью в такой репликации!?
vsb>Надо исследовать вопрос. Есть транзакционные кеши для хибернейта. Есть не очень транзакционные. В любом случае там транзакционность будет на каком то уровне, имхо, достаточном для вашего случая.
Транзакции планирую вынести на уровень БД, потому как с БД будут работать и другие системы.
G>>боюсь как бы GC не стал затыкаться при такой апликухи на серваке...
vsb>Современный GC может останавливать мир на небольшое время, но по идее в целом это не должно сильно отражаться на функционировании. Будет раз в минуту стопать на десятую секунды. Если что, есть Azul, это JVM с неостанавливающим мир GC. Денег стоит, правда.
vsb>>>Ставите кучку серверов с томкатом в каждом. Ставите один сервер с nginx-ом, настраиваете там распределение запросов по серверам. Если в сессии ничего не хранить кроме аутентификационных данных, то сессию можно не реплицировать и на nginx-е настроить, чтобы он по JSESSIONID выбирал бэкэнд, на который надо направлять запрос. Все мануалы по настройке есть в сети.
G>>вот мысли были об этом G>>на практике не делал такого?
vsb>Видел, сам не настраивал.
vsb>>>Моё имхо, не нужен вам кластер. Хороший физический сервер, без всяких виртуалок ставите туда базу, туда же томкат (чтобы байты по сети не гонять безтолку) и всё будет быстро работать.
G>>томкат это хорошо, но в качестве контейнера думал о GlassFish либо WildFly — что скажешь?
vsb>А там не тот же томкат внутрях? Если они лучше, можно и их. Раз Spring + Hibernate использовать собираетесь, JEE вроде ничего ценного не даст, будут просто лишние мегабайты на диске лежать. Можно хоть на Jetty стартовать, все эти HTTP стеки примерно одинаково устроены. Томкат я обычно ставлю "по дефолту" потому что привык и он даёт некие минимальные удобства (настройка через конфиги, старт-стоп, в винде можно сервис сделать), но это всё мелочи.
Здравствуйте, garryg, Вы писали:
G>Приветствую, G>планируем в компании разработку сайта и одним из требования высокая нагрузка (посещаемость 30к+ пользователей в пике 50к — 70к).
Это пара сотен запросов в секунду. Я бы советовал не заморачиваться, а делать простое приложение, работающее с БД. Ну и добавить кэш на каком-нибудь Redis'е или Memcached. Для базы — выдержит обычный PostgreSQL на большом узле, рекомендую взять c4.2xlarge на Амазоне.
Если начать заниматься eventual consistency и тонкостями репликации — вы в этом завязнете на полгода. И самое обидное будет, когда на сайт будут заходить на порядки меньше пользователей, чем рассчитывалось.
Если у вас реально будет 100500 пользователей в секунду — тогда начинайте думать что делать.
