Инсталиране на 1C-Битрикс Уеб клъстера

За да бъда честен първоначалната задача е да се опише колко е готино дребномащабни проекти в окончателното решение. Но в края на теста, всичко си дойде на мястото.

Битрикс Уеб клъстер "защо толкова лошо"

Първото нещо, което исках да се отбележи, когато пишете статията 1C-Битрикс Уеб клъстера. Част 1 е фактът, че е нормално да се съберат на клъстера и изпълняването на сайта е само на 5 опита. За да направите това, както би трябвало да се бръкнат по-дълбоко в рамките на конфигурационните файлове на уеб клъстер, за да се запознаят подробно настройките и като цяло как той събира сървър.

Предполагаме, че самата клъстера вече е инсталиран.

Да започнем с това, че файловете на възел 2 за 5 минути няма да се появят в резултат на неправилно конфигурирани синхронизатори.

Какво се случва в действителност?

Можете да синхронизирате клъстера, както и че ще работи! Вие наистина умножителите да поставите файла на всеки сървър и да ги смените с ум ще работи, но!

Когато първият опит да се повиши на сайта Битрикс на главен възел, можете да получите неочакван ефект, клъстера спира да работи.

По-подробен преглед ще разберат причините за такова действие. Синхронизатор csync2 файлове, когато за първи път започнете, всички валидно добавят и работи много прилично. За короната влизане на 5 мин на всеки файл, като използвате подходящ конфигурация, повече подробности може да се види в cron.d

Също така тя изглежда доста приличен

На свой ред, демонът, отговорен за сайтове за синхронизация сега заета от едно нещо, той събира огромен списък от файлове със скорост от 10-20 файлове в минута! В своята база данни. След това започва всеки файл в отделна сесия, за да обърне към нов сървър (със скоростта на копиране на файлове всъщност е по-ниска от FTP няколко пъти) като се има предвид мудността на съставянето на самата база данни, както и с много висока ненаситност към времето, IO, когато обикновената търговска площадка Битрикс се появява на втория възел за 21 часа! През цялото това време csync2 ще работи активно prosazhivaya I-O система на 98%. Без да се прави на практика нищо!

В резултат на това нормалната синхронизация за първи път, ще трябва да деактивирате синхронизирането на короната, отидете в Манчестър на csync2 и направете Първото синхронизиране ръцете си, ще отнеме стотици или дори хиляди пъти по-бързо, отколкото просто чака. Това е единственият начин!

Но не всички, че лошо, Bitrix се взема под внимание, и го прави при първата синхронизация на клъстера, оставяйки цялата архива на сайта си на нов възел, добре, наистина, той го прави с ext_ папка и за първи път има само нищо. Така, че функцията на този етап в Битрикс колата там, но тя събира толкова зле замислена, че действителното време на синхронизация ще трябва да направи първо с ръцете си.

И така, ние се синхронизира файлове и всичко това с ума, за да работи, откри нова SEK продължава да работи малко на брой файлове се синхронизират е доста приемливо, пари в брой, както можем да видим от конфигурационните файлове, за да не са синхронизирани на всички.

И тогава причината е ясна, със скоростта на копиране на малки файлове, по принцип можете да забравите за него като лош сън за.

Но това забавно не свършва дотук.

Ние добавяме второ място се каже test.kz и след това започнахме много смешно неща.

За да започнете синхронизация, дръжки първо място ние проверяваме дали всичко работи, и да сме започнали задачата на короната е цялата работа, че наистина се е паднал първият сайт!

Ние се изкачи в / и т.н. / ansible за разбор

Ние намираме точно такова прекрасно нещо,> = домейна си да се отбележи.

И аз имам две области test1.ru test1.kz

Следователно провери предполагам търси в конфигурационния

Следователно, нашите конфигурации за раздразнението, като тази променлива се използва в няколко други места, като така конфигурационния файл, а в короната и така нататък. Д., и така нататък. Н. По принцип, по-късно са открити тези грешки в повече от 57 места, в действителност от другата страна на клъстера от базата данни на балансьор. Повишаване на две еднакви sraznitsey домейн е невъзможно без пълно рязане клъстер! Между другото това също се отнася само за поставяне на двете места, те също ще бъде един малък проблем при създаването на база данни. Те също така ще бъде идентичен, и разгръщането на второто място, това е справедливо да се каже, че базата данни вече е заето.

Когато попитах за поддръжка на клиенти на невъзможността да се използва домейнът с разлика на ниво 1 милостив отговор беше: "Благодаря Ви, че се функция с многосайтово клъстер скоро ще бъде премахната"

Така че за регионални огледала Битрикс в бъдеще ще препоръча отделни сървърни шкафове!

На следващо място, аз говоря с безкрайността, много неща, които са очевидно с пълен разбор довереник и начина за създаване на клъстер изглежда достатъчно проста, но това е провал от гледна точка на управлението на.

Ето един бърз списък на проблемите, които са възникнали при мен в създаването на клъстера:

1. Стандартен монтаж на клъстера - синхронизация 879 Mb се 21 часа. с липсата на каквато и статут в панел или на интернет страницата.
2. След синхронизация Битрикс poskoku папка е изтрита от датата на създаване е нова версия на папката на възела на роб (тя е само dbcon.php създаден Битрикс клъстер. Да, това, което sozdaetsya грешка в представката на базата данни, ако едни и същи обекти на ниво домейн, 2.
3. Изтриване на тази директория като index.php в възел с роби, за да синхронизирате доведе до същия резултат csync2 просто убит тези файлове и директории на главния хост. Както казах преди Първото синхронизиране трябва да се извършва дръжки, стандартен метод е просто неработеща.
4. Конфигуриране за всички ubilis идентични домейни 2 нива.
5. Ефективност на сайта падна на около 200 пъти това се дължи на конфигурацията на робовладелеца за статично съдържание, съчетано с динамиката.
6. Клъстерът не може да работи с кеша вече писа по-горе.
7. Клъстерът не може да работи с CDN почти по същата причина.
8. Клъстерът не може да работи с композит.
9. Клъстерът не може да работи с HTML кеш.
10. А група от кутии невъзможно да изберете, просто няма меню за това, основната си конфигурация е най-лошият вариант от всички.
11. Cluster без дълбоки познания за Linux повиши просто невъзможно.
12. Cluster работи само на 1C-Битрикс виртуална машина, която и да е друг начин да го инсталирате е толкова трудно, че е 10 пъти по-лесно да се съберат си клъстер без използването на 1C-Битрикс. По принцип, това е така, дори и с използването на виртуална машина.
13. Много суров продукт като цяло, не само все още трудно се документира.
14. Заявление за представяне на Bitrix 14 относно включването на "клъстер" с 2 сървъри във всички основни решения пълни и откровени лъжи, на клъстера като един е "по-стари" редактира, така че остава.
15. В балансьор още няма ясни правила за това как да превключвате капитана роб възли.

Но първо първите неща.

Да кажем, че сме спечелили и файлове и бази данни са синхронизирани, че работи, но защо всичко това е ужасно бавно? Изпълнение в 1C-Битрикс падна до 0.2 от 170!

тогава причината за конфигурацията по подразбиране на клъстера.

Всичко, което прочетох за майстор-роб майстор-майстор и така нататък. Г. мултипликатори те хвърля в кошчето, 1C-Битрикс не са в състояние конфигурация ключ. Това е просто една лъжа, няма един ред код, отговорен за това. Тъй като няма един ред код показва вида на текущата конфигурация, точно както на документацията по този въпрос. Дори и в обучение Битрикс виртуална машина, вие няма да намерите местоположението на основата на основата на сглобени клъстера.

И това изглежда така!

Какъв умен и със сигурност зъл гений е предложил да се съберат на клъстера така че аз не знам, но от гледна точка на управлението на очевидно е провал!

Ето как изпълнението е променила:

Честно казано, не вярвам, че средната PHP програмист когото задачата да събира 1C-Битрикс клъстер. Качествено разбира Nginx глоба балансиране Linux администратор знае csync2 ansible и добре запознат с конфигурацията на Apache-Nginx.

Той току що вдигна Най-вероятно с мъка клъстер ще видите изпълнението на това събитие и ще хвърлят всичко в него! Тъй като не представянето на документи и няма къде да се копае, че не е напълно ясно.

Според мен, това е пълен провал на идеята!

За тези, които не разбират погрешността на конфигурацията на сървъра, ще опиша по-подробно.

И така, нека да кажем, че имаме разстоянието между 40ms сървъри, защото ние използваме различни центрове за данни.

По тази причина искането отидем първо до сървъра 1, а след това 2, след това 1, освен това, на SQL заявки последният, и всеки от тях ще добави 40 милисекунди. Причината при първото стартиране на клъстера не изглежда толкова добре позната за мен, но не искам да вярвам в нещо, което е просто в лицето на балансьор Nginx, който е написал сценария лентяй да добавите 1 ред код.

В действителност, за поставяне на втора машина е най-новите съобщения и следователно всички заявки за неизпълнение (тъй като не е предоставена никаква приоритет) ще отидат за него.

Само промяна седалките на автомобила в

и рестартиране на Nginx,

можем да получим първоначалната схема на сървъра, с добавянето на безотказен, но ние трябва да разберем, че на втория сървър все още ще има директива в dbcon.php домакин: server1.ru, а оттам и спад в базата данни все още няма да жизнеспособен.

Ето защо, за да завърши сайта на клониране, ние трябва да оставам база данни като Localhost от двете машини.

Да, за да завършите редовност, бих добавите правило за превключване между сървъри, защото това всъщност не е така, че да сочи надолу през цялото време, главен сървър за 30 секунди.

В тази конфигурация, мисля, че ще продаде клъстер.

Да функция на втория сървър прилича на тази настройка, просто дублира устройство. Въпреки очевидната падането на първи! И всичко, което може да го направи с пълното падането на първия (с изключение на Balancer) получи динамичен и статичен от втория възел, но всъщност се нуждаят от малък бизнес!

В крайна сметка, бизнес моделът на "клъстер от кутията" и означава малки и средни предприятия hh.ru и без ... себе си повишаване на клъстер. Следователно, малък сегмент от него само в два случая.

1. Сайтът на максималното време на разположение, има им резервна, дори и с ремапинг роб база данни на капитана след възстановяването на главен възел.
2. Посочете по-подробно причината за получаване на данни от роб възли, но това е в администратор никъде, според този "сървър извън кутията" трябва също, ако не даде конфигурирате тези настройки при стартиране, то поне да не потъне производителност.

На следващо място, бих описал много повече плюсове и минуси на прилагането Битрикс клъстер, но няма да се претовари на читателя по-подробни въпроси, които се опитват да отговорят на комети до гредата.

Единственото нещо, което бих искал да добавя, е как аз наистина исках да видя това решение:

1. Естествено, Bitrix клъстер работи изключително с Bitrix машина, тази промо Разбира се и това е късмет.
2. Отстраняване на грешки всички грешки и тяхното морето, защото няма начин да изберете конфигурация, за да създадете един единствен господар + роб балансьор и да вземат в облака Битрикс. В този случай, на клъстера ще бъде наистина отказоустойчива и в случай на повреда на машината напълно майсторски възли все още може да продължат да работят. И едно много важно предимство би било невъзможно да напусне Битрикс допълнително като стабилизатор някой трябва да държи.
3. Също така реших да имате проблем с теста Bitrix Site относно лиценза на клъстер, проверете съществуващите толкова лесно се разграждат, че аз просто не мога да го приведе в статията, като Битрикс златен партньор.
4. Най-важното, на клъстера трябва да се повдигане на обикновените потребители, трасира една единствена схема с ясно действие е много по-лесно, отколкото да се разбере по всичко.
5. Никой не забранява принуди потребителя да даде същите господар роб възли, домейни 3 нива от основния сайт, и така нататък. Д. ясна последователност от действия, макар и не за всеки вкус, но даде "готово решение", а не това, което имаме сега. Нека тя няма да се поберат всички, но ще работи!

ОБЩО отношение на администратор Linux:

Bitrix Virtual Machine скочи силно в изпълнение на един сайт, направихме много полезна, най-накрая добавя възможността за премахване на възел (в предишната версия, дори и това не е). Като цяло има добър тенденция, но когато става въпрос за влага, продукта от гледна точка на хостинг множество сайтове в момента е на работа, без да броим нещастен идеята за въвеждане на обекта в папката по подразбиране. За което бих искал да намали вашите ръце.

В крайна сметка, аз бях в състояние да реши проблема с изпълнението, правилно балансиране на натоварването, както и съставяне на еластична система, но прекарва много повече време, отколкото може да си позволи да се отпусне, в действителност за стабилна работа на системата трябваше да прекарат 3 пълни дни на работа.

Cluster решение е толкова влажен и толкова бавно, че използването на кутията е просто невъзможно.

Сглобяване на уеб клъстера Bitrix, дори и в добър администратор ще отнеме повече време, отколкото събира оръжие.

Up с перспектива PHP програмист на:

Всичко е просто клъстер докосва Битрикс програмист само един бод връщане към основната отговор вярно проверката за арматурното модул. Ако говорим от гледна точка на приложение, то обикновено е програмист не може да се приложи решение "1C-Битрикс Уеб клъстера."

ОБЩО по отношение на управлението

Толкова е просто, решението на 1C-Битрикс клъстер не съществува!

Възможно е да се направи допълнителни противоречия, но това не променя факта, че има решение да "продадат", това е невъзможно!

P.S специални благодарности на колегите от VPS сървър .ru, които са предоставили ме доброволец VPS сървъри за първоначалните тестове, но в крайна сметка аз вече работят по didicate сървъри, но в никакъв случай те ми помогнаха ще спестят много време.