- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Что делать, если ваша email-рассылка попала в спам
10 распространенных причин и решений
Екатерина Ткаченко

В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Но зачем?? Ладно git в отдельный контейнер. Но зачем гонять данные через сетевую от мускуля в ламп и на бэкенд, или от мускуля на мемкеш?
Всё правильно, чем больше изоляции, тем лучше. Если ресурсы позволяют обслуживать накладные расходы.
Всё правильно, чем больше изоляции, тем лучше. Если ресурсы позволяют обслуживать накладные расходы.
ага, а идеальная изоляция - обложить кирпичом, залить в цемент и закопать на глубину 5 метров.
Вижу только одну причину - перенос в дальнейшем контейнеров на отдельные дедики в случае роста. Тогда да - вполне красиво себе получится и практически ничего переставлять не нужно.
Вижу только одну причину - перенос в дальнейшем контейнеров на отдельные дедики в случае роста. Тогда да - вполне красиво себе получится и практически ничего переставлять не нужно.
Вот видите, Вы сами всё прекрасно поняли. Более того, можно даже не прерывать обслуживание клиентов. То есть при правильной архитектуре приложения и правильном изначальном разнесении частей системы на виртуальные сервера, можно с одного сервера расти до небес не прерывая работы. Главное изначально распилить как можно мельче и при этом не терять сильно в производительности.
Symfony висит в памяти и нагружает только базу. Бекенд нагружает только базу. nginx файловую систему не трогает. Lightppd нагружает файловую систему запросами на мелкие файлы, но чуть что - они выносятся в память/облако/космос. Memcached никого не трогает. В общем, диск грузит только база, что тоже не мало.
Все виртуалки будут нагружать диск и отнимать свои IOPS. По банальной причине - логи и служебные обращения. И если база грузит сильно, то остальные тоже будут тормозить. Так как заботитесь о дисках, то мой совет - базу и Lighttpd на SSD, всё остальное + бэкапы на SATA, 7200 🍿
Или всё на SSD а барахло по NFS куда нибудь....
Вот видите, Вы сами всё прекрасно поняли.
Тогда позволю себе продолжить рекламу своего коллеги - ibm c 2xE5-2620 в нашей стойке.
В случае разрастания найдем место под новый сервер и организуем по 2 гигабитных аплинка с каждого сервера. Первый аплинк смотрит наружу, на втором можно поднять приватную сеть между серверами.
Все виртуалки будут нагружать диск и отнимать свои IOPS. По банальной причине - логи и служебные обращения. И если база грузит сильно, то остальные тоже будут тормозить. Так как заботитесь о дисках, то мой совет - базу и Lighttpd на SSD, всё остальное + бэкапы на SATA, 7200
Давайте смотреть:
1. если умирает SSD-шка, то сервер должен ждать её замены и восстановления из бекапа;
2. если умирает SATA, то ложатся и все сервисы, потому что логи класть некуда;
3. если удачно отмониторили SSD-шку и вовремя заметили, что её нужно менять (и-таки убедили в этом хостера), то нужно останавливать сервер и подниматься из бекапа.
Если же есть RAID1, то вполне можно провести замену умершего диска не останавливая сервер. Главное, чтобы диск выдержал нагрузку и замена была достаточно быстрой - в течение пары дней.
Давайте смотреть:
1. если умирает SSD-шка, то сервер должен ждать её замены и восстановления из бекапа;
2. если умирает SATA, то ложатся и все сервисы, потому что логи класть некуда;
3. если удачно отмониторили SSD-шку и вовремя заметили, что её нужно менять (и-таки убедили в этом хостера), то нужно останавливать сервер и подниматься из бекапа.
Если же есть RAID1, то вполне можно провести замену умершего диска не останавливая сервер. Главное, чтобы диск выдержал нагрузку и замена была достаточно быстрой - в течение пары дней.
Правильно. Поэтому нужно и ssd и sata делать в рейд. И желательно железный.
Бэкап это правда не отменяет в любом случае.
А чтобы хостера не убеждать и чтобы он сам это делал, то берется администрируемый сервис, с гарантией работы железа и сети на таком-то uptime проценте.
то берется администрируемый сервис, с гарантией работы железа и сети на таком-то uptime проценте.
Есть таки красивые сказки. Только я в них почему-то не верю даже за большие деньги.
Чехия/Москва.
Supermicro, IPMI, 2 IP, порт выделенный безлимитный.
E3-1230 / 16Gb / 2x300Gb SAS / 100 Мбит выделенный безлимитный - 169 евро в месяц.
Возможны любые варианты серверов на базе Supermicro, установка 1 - 5 рабочих дня.
Давайте смотреть:
1. если умирает SSD-шка, то сервер должен ждать её замены и восстановления из бекапа;
2. если умирает SATA, то ложатся и все сервисы, потому что логи класть некуда;
3. если удачно отмониторили SSD-шку и вовремя заметили, что её нужно менять (и-таки убедили в этом хостера), то нужно останавливать сервер и подниматься из бекапа.
Если же есть RAID1, то вполне можно провести замену умершего диска не останавливая сервер. Главное, чтобы диск выдержал нагрузку и замена была достаточно быстрой - в течение пары дней.
Размышление человека, который где то слышал, но сам не ообенно разбирается. Делайте RAID1 на SATA и на SSD и делов то. Не надо оставатся на уровне 2006 года, когда SSD еще еле живы были, 2013 уже. SSD диски это уже повседневное явление, у меня даже на ноуте и то SSD .... Всё мониторится, теми же средствами mdadm или утилитой аппаратного рэйда, в случае проблем с рэйдом посылается предупреждение или по почте, если есть желание и SMS прикрутить можете.
RAID1 на SSD оверкил естественно, но если простой в 10 минут для развертывания бэкапа базы проблематично, то никуда от этого не денешься. Если уж на столько критичный проект, то можно ставить по диску для hotspare.
Софтварный рэйд даёт такую гибость, которую никoгда не получите с аппаратного, только думать надо, да и уметь естественно 🍿