Олег Шамаев (Все сообщения пользователя)

Извиняюсь, глупость написал, монтировать раздел для проверки на ошибки не требуется. Очень давно не видел подобных ошибок.

В первую очередь введите команду
т.е. выполните завершение работы ОС, и сделайте резервную копию виртуальной машины средствами гипервизора.


Далее:  
http://www.unixarena.com/2013/09/redhat-linux-how-to-fix-read-only-root.html  - попробуйте с п.6 подставив имя раздела который ОС считает сбойным.

В случае серьезных повреждений ФС, в рамках форума помочь Вам будет очень сложно.

VMBitrix тут не причем, скорее всего ВМ была некорректно выключена во время записи на диск(или нечто другое повлияло) - ОС считает, что с файловой системой не все в порядке и посему смонтировала основной раздел в режиме чтения. Т.е. Вам нужно авторизироваться, смонтировать раздел вручную в режиме чтения-записи и запустить тестирование раздела на ошибки. Ну и очевидно нужно позаботится, чтобы Ваш хост ESXi всегда корректно завершал работу виртуальных машин.

Полагаю Вы проводите замер неком рабочем сайте, т.е. отличном от свеже-установленного битрикса, думаю на нем отнюдь не пустой init.php в котором на каждом хите вызывается что-нибудь ресурсоемкое. Попробуйте, для чистоты замеров установить рядом демо той-же редакции и провести тест в на нем.
 

А Вы создали соответствующую запись в зоне домена?

в файле /etc/mysql/conf.d/z_bx_custom.cnf можно задавать и переназначать все нужные параметры. Поскольку этот файл подключается последним, указанные в нем значения переменных переназначат заданные в других конфигурационных файлах.  

Два года использования pdd.yandex.ru с почтой в нескольких доменах, 50 аккаунтов, через полгода пришлось отказаться от использования почтовых программных клиентов - отказы в работе служб smtp, pop, imap длительностью от нескольких минут до пары часов были почти еженедельно, при этом почта была доступна через веб и принималась серверами яндекса при отсылке напрямую.

По моему глубокому убеждению, в случае использования BitrixEnv/BitrixVM самый надежный и беспроблемный в дальнейшем способ организовать работу почты - это настройка postfix с отправкой почты напрямую, с DKIM и SPF записями в зоне домена от имени которого почта отправляется. Могу написать пошаговую инструкцию как это все настроить, при явной потребности сообщества в сем.    

Вероятно я ошибся, нет под рукой работающего сервера с интеграцией в AD, возможно повысить уровень логирования нужно в /etc/httpd/bx/conf/mod_ntlm.conf

Алексей, тут http://dev.1c-bitrix.ru/community/forums/forum32/topic66532/ про идею превращения BitrixEnv в площадку для шаред-хостинга. Забудьте о множестве сайтов в одном веб-окружении, если для Вас важна безопасность.  

memcached не оказывает на производительность bitrix практически никакого влияния. Совокуплять xcache c memcache не имеет смысла и то и другое будет хранить кеш? Мне не приходило в голову это делать ни разу, но по моему мнению это невозможно. Могу ошибаться.  

Рустам, это сообщения указывают на то, что запрашиваемое у DNS сервера доменное имя - не найдено, т.е. либо действительно имени не существует, либо у вашего сервера/виртуальной машины в данный момент нет доступа к DNS серверу.

Возможно Вы не включили в настройках модуля "AD/LDAP интеграция" - "Включить переадресацию NTLM авторизации:"

Дмитрий, вот так выглядит в логе апача при включении уровня логирования debug авторизация пользователей домена, пишется явное имя пользователя и имя домена(заменены на ***):
Если Вы не наблюдаете в логах такого, то возможно:
1. Вы не включили логирование как описано выше, или включили не для портала, если у Вас несколько сайтов. Что делать полагаю очевидно.  
2. Попытки авторизации нет вообще, возможно проблема локальная, т.е. вы не выполнили какое то требование при внедрении.  

Дмитрий, полагаю не имеет смысла спрашивать, из каких бразеров ходят пользователи, добавлен ли хост портала в "Надежные сайты", сам портал не выдает ошибки при проверках и прочие банальности?

Попробуйте в /etc/httpd/bx/conf/default.conf заменить строчку:
LogLevel warn
на
LogLevel debug

далее service httpd restart

Попробуйте войти на сайт с любого компьютера в домене и выложите сюда часть лога /var/log/httpd/error.log за период в котором была попытка авторизации.      

Михаил, это слишком обширная тема, чтобы ее подробно обсуждать на форуме.
NAT не используют, по крайней мере в том виде в котором он реализован в "бытовых" роутерах. На шаред-хостингах, один сервер, с одим ip может держать несколько сотен сайтов, без NAT конечно.

Вы не сможете с одним единственным каналом провайдера, бытовым роутером с NAT и одним-двумя хостами с esxi(угадал? без систем хранения данных?) обеспечить доступность Ваших сайтов близко к 99%. Ввиду неминуемых регуляторных сбоев в том или ином месте, а значит периодической недоступности сайтов, ваша внушительная CEO оптимизация пойдет лесом - тот же яндекс, все ваши сайты будет понижать в ранжировании по причине плохой доступности.

Арендуйте VDS у хостера для публичных сайтов в нормальном датацентре, с резервированием каналов и. пр., а разработку ведите на своих мощностях.

Думаю, множество сайтов располагать за NAT можно, только если сайты с очень низкой посещаемостью, им не требуется полноценное индексирование поисковиками, т.е. например у вас несколько корпорталов(?) без публичного доступа. NAT это довольно ресурсоемко, даже небольшой ddos на Ваш ip даст очень большую нагрузку на роутер, и если это не cisco за много $$, ваш роутер скорее всего ляжет.
Если Вам действительно необходимо разделить сайты по соображениям безопасности, по разным ВМ, при этом сохранить NAT(?), то выходом может быть проксирование трафика с помощью nginx - создаете небольшую ВМ с Linux, устанавливаете на нее nginx, с директивами проксирования для каждой группы доменных имен на соответствующие ВМ с адресами внутренней подсети, т.е. транслирование адреса(NAT) внешнего ip должно производится на внутренний ip ВМ c проксирующем nginx. А еще лучше арендуйте у вашего провайдера подсеть /29 и уберите NAT для сайтов.                  

Не очень понял, что на графике, если это график ping-ов от какого то узла до Вашего VDS, то это очень плохо - длительные периоды с ответами свыше 1000мс (100мс уже плохо). Если это не проблема узла с которого осуществляется мониторинг, могут быть сложности с индексацией сайта поисковыми машинами, а до некоторых узлов пакеты вообще могу не доходить при наложении задержек, например от пользователей с радио-модемами, полагаю последствия очевидны.

VM Bitrix, это ОС Centos 6.5 c уже установленным BitrixEnv(веб-окружением), т.е. если на свежеустановленный Centos 6.5 установить BitrixEnv получится ровно тоже самое. Некоторые хостеры создают (вне зависимости от типа виртуализации) свои варианты VM Bitrix, т.е. устанавливают Centos, на него BitrixEnv и как правило еще пару тайных ингредиентов - раскопать что это такое и к каким последствиям приведет, порой бывает очень сложно. Посему если хостер предоставляет возможность самостоятельной установки ОС, лучше воспользоватся ей - установить Centos например отсюда http://mirror.yandex.ru/centos/6.5/isos/x86_64/CentOS-6.5-x86_64-minimal.iso и дальше по сценарию.

Если тип виртуализации OpenVZ, установка ОС невозможна, контейнеры(виртуальные машины) создаются на основе заранее подготовленных темплейтов. В Вашем случае хостер видимо самостоятельно создает темплейты на основе дистрибутивов ОС и как я писал ранее, неизвестно, что именно было изменено относительно базовой ОС. Возможно хостер банально изменил репозитарии ПО на свои локальные, тогда достаточно будет подключить официальные, в любом случае гадать можно бесконечно. Напишите в тп хостера, что пакет BitrixEnv при установке выдает такие то ошибки и не выдает при установке на официальный дистрибутив Centos. Если не поможет, меняйте хостера, например на timweb.    

Артем, посмотрел на Ip-сайта указанного у Вас в профиле 77.72.129.222, адрес ожидаемо принадлежит Colobridge GmbH:

Пинг из датацентра в СПБ, sel ectel, канал 1Гб, загрузка канала в момент пинга близка к нулю(8 утра, суббота)

[root@host03 ~]# ping 77.72.129.222
PING 77.72.129.222 (77.72.129.222) 56(84) bytes of data.
64 bytes from 77.72.129.222: icmp_seq=1 ttl=59 time=58.5 ms
64 bytes from 77.72.129.222: icmp_seq=2 ttl=59 time=58.5 ms
64 bytes from 77.72.129.222: icmp_seq=3 ttl=59 time=58.5 ms
64 bytes from 77.72.129.222: icmp_seq=4 ttl=59 time=58.5 ms
64 bytes from 77.72.129.222: icmp_seq=5 ttl=59 time=58.5 ms
64 bytes from 77.72.129.222: icmp_seq=6 ttl=59 time=58.5 ms
64 bytes fr om 77.72.129.222: icmp_seq=7 ttl=59 time=58.5 ms

Пинг от узла в Н.Новгороде, канал 70Мб

C:\FAR>ping 77.72.129.222 -t

Обмен пакетами с 77.72.129.222 по с 32 байтами данных:
Ответ от 77.72.129.222: число байт=32 время=170мс TTL=45
Ответ от 77.72.129.222: число байт=32 время=155мс TTL=45
Ответ от 77.72.129.222: число байт=32 время=149мс TTL=45
Ответ от 77.72.129.222: число байт=32 время=140мс TTL=45
Ответ от 77.72.129.222: число байт=32 время=140мс TTL=45
Ответ от 77.72.129.222: число байт=32 время=145мс TTL=45
Ответ от 77.72.129.222: число байт=32 время=153мс TTL=45
Ответ от 77.72.129.222: число байт=32 время=142мс TTL=45
Ответ от 77.72.129.222: число байт=32 время=140мс TTL=45

Странно, при попытке отправить в сообщении данные трассировки выдается ошибка "Введите сообщение".  В общем трассировки тут https://yadi.sk/i/r7iid67hbZoUD

Конечно для полной картины нужно мониторить канал из 5-6 точек одновременно в течении 2-3 дней, но думаю это уже излишни.

Примерно раз в полгода(на протяжении последних 5 лет) устраиваю тестирование различных зарубежных хостеров(в ЕС в основном) на предмет арендовать пару тройку серверов (дешево же!), почти все хорошо кроме каналов из РФ, где как правило 99% пользователей обитает которые пойдут на сайты.
У меня в доступности каналы крупных провайдеров из нескольких городов европейской части РФ.
Я не видел ни разу, чтобы ping из РФ до любого приличного хостера находящегося в ЕС был ниже 50мс, а в среднем 130мс, в рабочие часы скачет вплоть до потерь. Для сравнения ping до датацентров selectel, timweb(не реклама) редко когда поднимается выше 20мс.  

По большому счету, тип виртуализации не имеет значения для арендатора VDS, все зависит от честности хостера и квалификации его администраторов. У OpenVZ самые низкие накладные расходы по ресурсам сервера, т.е. теоретически один "железный" сервер сможет выполнять большее количество VDS, чем сервера с XEN и KVM, посему OpenVZ дешевле. Ну а соблазн у хостеров впихнуть на одну железку как можно больше VDS очень велик, и не все его могут преодолеть, в результате арендатор VDS наблюдает периодические неожиданные и плохообъяснимые тормоза. Впрочем для XEN и KVM это тоже справедливо, но в меньшей степени.

Евгений, на мой взгляд Вам правильно порекомендовал timweb, не беспроблемный хостинг VDS, но по соотношению цена/плюшки очень неплохой.

Если у вас основная нагрузка от сайта ложится на php, то самым важным ресурсом будет CPU, чем больше мегагерц тем быстрее будет работать (одно ядро E3-1270v2 3,5Гц примерно в полтора раза быстрее чем E5-2630v2 2,6Гц, хотя по стоимости сервер на базе первого CPU будет значительно дешевле)
Объем необходимой памяти можно вычислить нагрузочным тестом имитирующем расчетное количество пользователь, например с помощью jmeter, либо периодическим просмотром логов на предмет срабатывания OOM killer, что будет однозначным сигналом - памяти не хватает.  Тут трудно что-либо сказать определенное, полагаю ошибки связанны с мнением хостера, каким должен быть идеальный teplate Centos для их сервера c OpenVZ, попросту неизвестно как его делали. Попросите поставить на Ваш VDS темплейт отсюда http://openvz.org/Download/templates/precreated

Анна, ftp это не выход, а дыра в сервере, при определенном стечении обстоятельств ломается ботами без непосредственного участия злоумышленников.
И человек написал, что не имеет опыта администрирования linux, т.е. шанс, что он сможет установить и сконфигурировать безопасный, насколько это возможно, vsftpd почти равен нулю.  

В рамках BitrixEnv сделать такое разделение без потери в дальнейшем возможности обновления BitixEnv сделать очень сложно. Насколько я понимаю веб-окружение не проектировалось для функций массового хостинга.
Самый простой вариант разделения сайтов по условным группам безопасности при сохранении типового функционала BitrixEnv это множество виртуальных машин. Для экономии ресурсов, в случае "железного" сервера это контейнерная виртуализация OpenVZ и множество контейнеров(виртуальных машин) с BitrixEnv.

В BitrixEnv и соответственно VM Bitrix создается(создан) пользователь "bitrix" от имени которого запускаются службы nginx и apache(httpd), т.е. веб-сервера, и этот пользователь является владельцем /home/bitrix/*, т.е. всех каталогов с сайтами.
Если Вы предоставите разработчику учетные данные пользователя bitrix, к настройкам сервера разработчик иметь доступа не будет.

Поддержка протоколов sftp(SSH File Transfer Protocol) и ssh осуществляется одной службой sshd, разделить доступ по этим протоколам возможно, но довольно трудоемко и не имеет смысла по большому счету.

Думаю Вам лучше нанять профессионального администратора, в рамках форума советовать в столь неоднозначной ситуации сложно. И тот и другой вариант потенциально могут работать эффективно.

При выполнении все требований совместимости к хостингу(серверу) интеграция будет работать.    

Установка BitrixEnv 4.3 или 5 на Centos 7, без существенной переделки оного BitrixEnv невозможна, слишком серьезны различия 6 и 7(systemd например), проще самостоятельно сконфигурировать аналог на базе конфигов развернутого окружения, если конечно совсем приспичит(?). К том же, на мой взгляд Centos 7 еще не достаточно "созрела" для применения в продакте.