Розробка інформаційного веб-сайту з використанням мови програмування PHP

Ініціатором є німецький розробник Тобіас Ратшіллер (Tobias Ratschiller) і базується, так само як і phpPgAdmin, на аналогічному застосунку MySQL-Webadmin, що виник у 1997 році.

Проект локалізовано понад 50-ма мовами.

Для встановлення phpmyadmin необхідно ввести команду:

sudo apt-get install phpmyadmin

Так як репозиторій свіжий, то пакет phpmyadmin в процесі установки запитає пароль для доступу до бази даних mysql (там він створює свої таблиці з налаштуваннями) і логін і пароль для свого постійного використання.

Після цього перезапускаю апач командою:

sudo /etc/init.d/apache2 restart

Також необхідно встановити Samba file server, для мережевої файлової системи.

Samba -- вільна реалізація мережевого протоколу SMB/CIFS. Samba випускається під ліцензією GNU. Назва Samba походить від SMB -- назви протоколу, який використовується Microsoft Windows для мережевої файлової системи. Головною перевагою Samba є те, що з її допомогою можливо використовувати у мережі одночасно комп'ютери з операційними системами Windowsта Unix, організовувати обмін файлами між ними без окремого Windows-сервера.

Починаючи з третьої версії Samba надає служби файлів і друку для різних клієнтів Microsoft Windows, і може інтегруватися з Windows Server: або як Основний контролер домену (PDC), або як член домену. Вона також може бути частиною домену Active Directory. З версії 3 Samba підтримує файлові сервіси та сервіси для друку.

Виконується на більшості Юнікс-подібних систем, таких як: Linux, Solaris, BSD, Mac OS X Server. Входить до більшості дистрибутивів Лінукс. В OS/2 портований samba-клієнт, плагіном до віртуальної файлової системи NetDrive.

Головною відмінністю від серверних версій Windows є відсутність підтримки для групових політик (непряма підтримка в принципі можлива) і налаштувань профайлів користувачів і комп'ютерів.

Встановлення Samba file server відбувається командою:

sudo apt-get install samba

для безпечного з'єднання необхідно встановити OpenSSH.

OpenSSH -- відкрита реалізація клієнта і сервера для роботи за протоколами SSH та SFTP, набір програм, що надають шифрування сеансів зв'язку у комп'ютерних мережах. Він був створений під керівництвом Teo де Раадта як відкрита альтернатива власницькій реалізації від SSH Communications Security.

Встановлення відбувається командою:

sudo apt-get install openssh-server

Все, тепер ssh-сервер встановлений та запущений.

Щоб його зупинити/запустити/запустити знову треба ввести команду:

sudo /etc/init.d/ssh stop | start | restart

Для того щоб під'єднатися до серверу через ssh треба в терміналі ввести:

ssh user@host

де user - ім'я користувача.

host - ім'я, або IP-адреса сервера.

Для підключення з windows необхідно використати PuTTY.

Конфігураційний файл openssh-server знаходиться:

/etc/ssh/sshd_config

Встановлення dns-серверу bind також є важливим, для нашоно серверу.

Доменна система імен (Domain Name System, DNS) - це розподілена база даних, яка містить інформацію про комп'ютери (хости), підключені до мережі Інтернет. Найчастіше інформація включає ім'я машини, ІР-адресу та дані для маршрутизації пошти.

Для звернення до хостів в мережі Інтернет використовуються 32-розрядні ІР-адреси, що однозначно ідентифікують будь-який комп'ютер в цій мережі. Однак для користувачів застосування ІР-адрес при звертанні до хостів є незручним. Тому було створено систему перетворення імен, яка дозволяла б комп'ютеру у випадку відсутності у нього інформації про відповідність імен та ІР-адрес отримати необхідні відомості від DNS-сервера, ІР-адреса якого зберігається в налаштуваннях підключення до Інтернет.

Таким чином, основне завдання DNS - перетворення імен комп'ютерів в ІР-адреси і навпаки.

Для реалізації системи DNS було створено спеціальний мережений протокол DNS. В мережі також є спеціальні виділені інфомаційно-пошукові сервери - DNS-сервери.

DNS-сервери (сервери імен DNS) - це комп'ютери, на яких зберігаються ті частини бази даних простору імен DNS, за які дані сервери відповідають, і, на яких функціонує програмне забезпечення, що обробляє запити DNS-клієнтів і видає на них відповіді.

DNS-клієнт - це будь-який мережений вузол, який звернувся до DNS-сервера для перетворення імені вузла в ІР-адресу чи, навпаки, ІР-адреси в ім'я вузла.

Основою DNS є уявлення про ієрархічну структуру доменного імені. Кожен сервер, відповідальний за ім'я, може передавати відповідальність за наступну частину домена іншому серверу (з адміністративної точки зору - іншій організації чи людині). Це дозволяє скласти відповідальність за актуальність інформації на сервери різних організацій (людей), що відповідають тільки за «свою» частину доменного імені.

Характеристики DNS:

- Розподіленість адміністрування (відповідальність за різні частини ієрархічної структури несуть різні люди чи організації)

- Розподіленість зберігання інформації (кожен вузол мережі в обов'язковому порядку повинен зберігати тільки ті дані, як івходять в зону його відповідальності і (можливо) адреси кореневих DNS-серверів)

- Кешування інформації (вузол може зберігати деяку кількість даних не із своєї зони відповідальності для зменшення навантаження на мережу)

- Ієрархічна структура (усі вузли об'єднані в дерево, і кожен вузол може або самостійно визначати роботу розміщених нижче вузлів, або передавати їх іншим вузлам)

- Резервування (за зберігання і обслуговування своїх вузлів (зон) відповідають (зазвичай) кілька серверів, розмежованих як фізично, так і логічно, що забезпечує збережуваність даних та продовження роботи навіть у випадку збою одного з вузлів).

Як працює DNS.Для перетворення імен машин в ІР-адреси програми прикладного рівня, такі як Netscape Navigator і т. п., викликають підпрограму gethostbyname. Якщо конфігурація машини передбачає використання DNS, gethostbyname запитує адресу в сервера імен, ІР-адреса якого вказана в налаштуваннях підключення до Інтернет.

Сервери імен бувають рекурсивними та нерекурсивними. Нерекурсивний сервер діє наступним чином: якщо у нього є адреса, кешована з попереднього запиту, або якщо вона авторитетна для домена, до якого відноситься ім'я, то він дає відповідну відповідь. В протилежному випадку замість правильної відповіді він відсилає до авторитетних серверів іншого домена, які повинні знати відповідь.

Рекурсивний сервер повертає тільки реальні відповіді та повідомлення про помилки. Базова процедура обробки запиту по суті така ж; єдина відмінність полягає в тому що цей сервер імен сам займається обробкою відсилок (відсилань), не передаючи їх клієнту.

Проте у відслідковуванні сервером відсилань є один побічний ефект: у його кеш надходить інформація про проміжні домени. Серверу домена високого рівня (такого як com чи ua) не рекомендується зберігати інформацію, що запитується машиною, розміщеною на кілька рівнів нижче. Його кеш швидко наповниться, і через додаткові затрати часу на обробку рекурсивних запитів пропускна здатність сервера знизиться.

У зв'язку з цим сервери імен нижчих рівнів зазвичай є рекурсивними, а сервери вищих рівнів (верхнього чи частково другого) - нерекурсивними.

Динамічний DNS - технологія, що дозволяє інформації на DNS-сервері оновлюватися в реальному часі, і (за бажанням) в автоматичному режимі. Вона застосовується для присвоєння постійного доменного імені пристрою (комп'ютеру, мереженому накопичувачу) з динамічною ІР-адресою. Це може бути ІР-адреса, отримана по DHCP чи по IPCP в РРР-з'єднаннях (наприклад, при віддаленому доступі через модем). Інші машини в Інтернеті можуть встановлювати з'єднання з цією машиною по доменному імені і навіть не знати, що ІР-адреса змінилася.

Динамічна DNS також часто застосовується в локальних мережах, де клієнти отримують ІР-адресу по DHCP, а потім реєструють свої імена в локальному DNS-сервері.

Приклади управління службою DNS:

- установка служби DNS;

- створення основної та додаткової зони прямого перегляду;

- створення зони оберненого перегляду;

- виконання динамічної реєстрації вузлів в зоні.

Зона прямого перегляду (forward lookup zone) - зони, які служать для перетворення імен вузлів в ІР-адреси. Найчастіше для цього використовуються записи типу A, CNAME, SRV.

Зона оберненого перегляду (reverse lookup zone) - зони, які служать для визначення імені вузла за його ІР-адресою. Основний тип запису PTR.

Порядок встановлення DNS серверу:

Ввожу команду для встановлення:

sudo apt-get install bind9

Судячи по документації та порадах багатьох системних адміністраторів, bind настійно рекомендують запускати в chroot середовищі. Для цього спочатку треба зупинити bind:

/etc/init.d/bind9 stop

Щоб вказати серверу, що він повинен запускатися в chroot середовищі потрібно відредагувати такий файл /etc/default/bind9 командою:

nano /etc/default/bind9

Змінивши в ньому стрічку OPTIONS="-u bind" на OPTIONS="-u bind -t /var/lib/named".

Тепер потрібно створити всі необхідні для роботи bind в chroot середовищі директорії, як це показано в лістингу 1.2.

Лістинг 1.2 - Створення директорій

mknod /var/lib/named/dev/null c 1 3

mknod /var/lib/named/dev/random c 1 8

chmod 666 /var/lib/named/dev/null /var/lib/named/dev/random

chown -R bind:bind /var/lib/named/var/*

chown -R bind:bind /var/lib/named/etc/bin

Тепер потрібно видалити налаштування bind з apparmor, так як apparmor стає непотрібним, при запуску bind в chroot середовищі:

rm /etc/apparmor.d/usr.sbin.named

Перезапускаю apparmor:

/etc/init.d/apparmor restart

Запускаємо bind9 :

/etc/init.d/bind9 start

Якщо все зроблено правильно, то помилок бути не повинно. Якщо bind раптом не запустився, то варто перевірити /var/log/syslog на наявність помилок:

tail/var/log/syslog

Якщо все працює правильно, то потрібно приступити до налаштування зони для мого домену domain.com

Створюю файл конфігурації зон:

nano /var/lib/named/etc/bind/zones.conf

З наступним змістом :

zone " domain.com" {

type master;

file "/etc/bind/domain.com"};

Встановлюю його власника:

chown bind:bind/var/lib/named/etc/bind/zones.conf

Редагую файл конфігурації bind, щоб він чіпляв конфігурацію зон:

nano/var/lib/named/etc/bind/named.conf

Додаю в нього рядок include " zones.conf " ;

Залишилося лише створити файл зони domain.com:

nano/var/lib/named/etc/bind/domain.com

З наступним змістом, який приведений у лістингу 1.3.

Лістинг 1.3 - Вміст файлу зони domain.com

$ TTL 86400

@ IN SOA ns1.domain.com . root.domain.com . (

2010081301 ; Serial

3600 ; Refresh

900 ; Retry

604800 ; Expire

86400 ; Minimum

) ;

@ IN NS ns1.domain.com .

@ IN A 192.168.1.1

ns1 IN A 192.168.1.1

ns2 IN A 192.168.1.1

www IN CNAME @

domain.com - відповідно ім'я вашого домену. Поміняйте значення перед параметром ; Serial на поточну дату. Останні цифри в рядку з датою ( 01 ) позначають скільки разів раз зона редагувалася за поточну добу. Так само не забудьте поміняти IP адреса, з яким ви пов'язуєте свій домен (192.168.1.1).

Після збереження файлу виставляємо його власника:

chown bind:bind/var/lib/named/etc/bind/domain.com

Все готово. Тепер залишилося оновити конфігурацію bind командою

rndc reload

І перевірити роботу сервера:

nslookup domain.com 127.0.0.1

Якщо все працює вірно, то відповідь сервера буде виглядати так само, як це приведено в лістингу 1.4.

Лістинг 1.4 - Відповідь з сервера

Server : 127.0.0.1

Address: 127.0.0.1 # 53

Non- authoritative answer :

Name: domain.com

Address: 192.168.1.1

На цьому налаштування DNS серверу завершена.

Піступним кроком є встановлення серверу електронної пошти sendmail.

Поштовий сервер, сервер електронної пошти -- в системі пересилки електронної пошти так зазвичай називають агент пересилання повідомлень (англ. mail transfer agent, MTA). Це комп'ютерна програма, яка передає повідомлення від одного комп'ютера до іншого. Зазвичай поштовий сервер працює «за лаштунками», а користувачі мають справу з іншою програмою - клієнтом електронної пошти (англ. mail user agent, MUA).

Наприклад, в поширених конфігураціях клієнтом пошти користувача є Outlook Express, повноцінна версія Microsoft Outlook, або Mozilla Thunderbird. Коли користувач набрав повідомлення і посилає його одержувачу, поштовий клієнт взаємодіє з поштовим сервером, використовуючи протокол SMTP. Поштовий сервер відправника взаємодіє з поштовим сервером одержувача (безпосередньо або через проміжний сервер -- релей). На поштовому сервері одержувача повідомлення потрапляє в поштову скриньку, звідки за допомогою агента доставки повідомлень (англ. mail delivery agent, MDA) доставляється клієнту одержувача. Часто останні два агенти суміщені в одній програмі (наприклад, sendmail), хоча є спеціалізовані MDA, які в тому числі займаються фільтрацією спаму. Для фінальної доставки отриманих повідомлень використовується не SMTP, а інший протокол -- часто POP3або IMAP -- який також підтримується більшістю поштових серверів. Хоча у найпростішій реалізації MTA досить покласти отримані повідомлення в особисту теку користувача уфайловій системі центрального сервера («поштова скринька»).

Часто поштовий сервер включає програмне забезпечення для організації розсилок електронної пошти.

Sendmail -- один з найстаріших агентів передачі пошти (MTA -- mail transfer agent). Програма розробляється Sendmail Inc. та розповсюджується безплатно разом з сирцевим кодом. Існують версії програми для практично всіх операційних систем іапаратних платформ.

Delivermail, програма, яка послужила основою для sendmail, була створена в 1979 і йшла в комплекті з 4.0 і 4.1 BSD і дещо пізніше дороблена Еріком Оллманом (Eric Allman).

Sendmail вперше був включений до складу 4.1c BSD (перша версія BSD, в яку був включений стек протоколів TCP/IP).

Встановлення серверу електронної пошти відбувається наступним чином:

Ввожу команду

sudo apt-get install sendmail

Потім ввожу команду

sudo sendmailconfig

після цього вводяться зміни в наступні файли

/etc/mail.sendmail.conf

/etc/cron.d/sendmail

/etc/mail/sendmail.mc

Також дуже важливим є встановлення FTP серверу, для швидкого закачування файлів на сервер.

Протокол передачі файлів (англ. File Transfer Protocol, FTP) -- дає можливість абоненту обмінюватися двійковими ітекстовими файлами з будь-яким комп'ютером мережі, що підтримує протокол FTP. Установивши зв'язок з віддаленим комп'ютером, користувач може скопіювати файл з віддаленого комп'ютера на свій, або скопіювати файл з свого комп'ютера на віддалений.

При розгляді FTP як сервісу Інтернет мають на увазі не просто протокол, а саме сервіс -- доступ до файлів, які знаходяться у файлових архівах.

FTP -- стандартна програма, яка працює за протоколом TCP, яка завжди поставляється з операційною системою. Її початкове призначення -- передача файлів між різними комп'ютерами, які працюють у мережах TCP/IP: на одному з комп'ютерів працює програма-сервер, на іншому -- програма-клієнт, запущена користувачем, яка з'єднується з сервером і передає або отримує файли через FTP-сервіс. Все це розглядається з припущенням, що користувач зареєстрований на сервері та використовує логін та пароль на цьому комп'ютері.

Ця риса послужила причиною того, що програми FTP стали частиною окремого сервісу Інтернету. Справа в тому, що доволі часто сервер FTP налаштовується таким чином, що з'єднатися з ним можна не тільки під своїм ім'ям, але й під умовним іменем anonymous -- анонім. У такому випадку для користувача стає доступною не вся файлова система комп'ютера, а лише деякий набір файлів на сервері, які складають вміст серверу anonymous FTP -- публічного файлового архіву. Отже, якщо користувач хоче надати у вільне користування файли з інформацією, програмами і т. і., то йому достатньо організувати на власному комп'ютері, включеному в Інтернет, сервер anonymous FTP. Створення такого серверу -- процес доволі простий, програми-клієнти FTP вельми розповсюджені, -- тому сьогодні публічні файлові архіви організовані в основному як сервери anonymous FTP. Перелік інформації, яка міститься на таких серверах, включає всі аспекти життя: від звичайних текстів домультимедіа.

Не зважаючи на розповсюдженість, у FTP є багато недоліків. Програми-клієнти FTP не завжди зручні і прості у користуванні. Користувач не завжди може зрозуміти який файл перед ним, чи той що необхідно, чи ні. Окрім того, не існує простого і універсального засобу для пошуку на серверах anonymous FTP, -- хоча для цього і існує спеціальний сервіс archie, але це незалежна програма, вона не універсальна і не завжди її можна ефективно застосовувати. Програми FTP доволі старі і деякі їхні особливості, які були потрібні в часи їхнього створення, не зовсім зрозумілі і потрібні зараз. Наприклад, для передачі файлів існує два режими -- двійковий та текстовий, і, якщо користувач неправильно обрав режим передачі, то файл, який необхідно передати, може бути пошкодженим. Опис файлів на сервері видається у форматі операційної системи серверу, а список файлів операційної системи UNIX не завжди з розумінням сприймається користувачами DOS. Сервери FTP нецентралізовані, -- звідси випливають ще деякі проблеми. Але незважаючи на все це, сервери anonymous FTP сьогодні -- це стандартний шлях організації публічних файлових архівів в Інтернеті.

FTP -- сервіс прямого доступу, який вимагає повноцінного підключення до Інтернету, але є можливість доступу і через електронну пошту -- існують сервери, які пересилають за допомогою електронної пошти файли з будь-яких серверів anonymous FTP. Проте цей шлях отримання інформації - досить незручний, оскільки такі сервери можуть бути сильно завантажені і запит доволі довго чекатиме своєї черги. Крім того, великі файли при пересилці діляться сервером на частини обмеженого обсягу і, якщо одна з частин загубиться і буде пересланою із пошкодженнями, то весь файл стане непридатним.

Встановлення та налаштування:

Встановлюється пакет proftpd за допомогою команди:

sudo aptitude install proftpd

Якщо FTP-сервер не використовуватиметься постійно відповісти на питання, що з'явилося, про спосіб запуску, необхідно: "самостійно".

Відкриваю файл /etc/shells командою:

sudo nano/etc/shells

Додаю в нього рядок

/bin/false

Створюю в /home каталозі папку FTP-shared командою:

sudo mkdir /home/FTP-shared

Створюю користувача з ім'ям userftp командою

sudouseradd userftp - p pass - d /home/FTP - shared - s /bin/false

де "pass" -- пароль.

В папці FTP-shared створюю дві вкладені папки:

sudo mkdir /home/FTP-shared/public

sudo mkdir /home/FTP-shared/upload

Присвоюю потрібні права створеним текам командами

sudo chmod 755 /home/FTP-shared

sudo chmod 755 /home/FTP-shared/public

sudo chmod 777 /home/FTP-shared/upload

Переіменовую наявний конфігураційний файл proftpd.conf і створюю новий:

sudo mv /etc/proftpd/proftpd.conf

/etc/proftpd/proftpd.conf.old

sudo nano/etc/proftpd/proftpd.conf

Якщо треба зробити анонімний доступ, слід закоментувати обидві секції для donet і розкоментувати секцію для аноніма.

Cервер вже запущений, але з параметрами за замовчуванням. Його необхідно перезапустити:

sudo /etc/init.d/proftpd restart

Для перевірки синтаксису створеного конфіг-файлу можна виконати: sudo proftpd - td5

Щоб взнати, хто підключений до фтп-серверу в даний момент використовується команда ftptop (клавіша t міняє відображення, q - вихід) можна також використати команду ftpwho

Фтп-сервер з двома папками, одна з них (public) доступна тільки для читання, інша (upload) - для запису.

Отже, уже є готовий сервер і сайт, але вони доступні тільки локально. Тепер зробимо його доступним ззовні.

ПК із Ubuntu Server відставляємо і далі будемо працювати з ним через SSH. Я використаю для цього PUTTY.

У першу чергу необхідно налаштувати файл підкачування.

Для цього створюємо файл заповнений нулями:

sudo dd if=/dev/zero of=/swap bs=1M count=2048

Підготовляємо його для використання як swap:

sudo mkswap /swap

Додаємо у файл fstab наш створений файл для використання як файл підкачування:

sudo nano /etc/fstab/swap none swap sw 0 0

Перезавантажуємося:

sudo shutdown -r now

Відразу ж обновляємо всі пакети, робиться це двома командами:

sudo apt-get update

sudo apt-get upgrade

Для керування системою через веб-інтерфейс необхідно мати пакет webim, але його на жаль у репозитарії немає, тому завантажую підготовлений пакет вручну:

wget http://prdownloads.sourceforge.net/webadmin/webmin_1.580_all.deb

Для установлення webim будуть потрібні деякі залежні пакети.

sudo apt-get install libnet-ssleay-perl libauthen-pam-perl libio-pty-perl apt-show-versions

Встановлення виконується командою:

sudo dpkg --install webmin_1.580_all.deb

Все, можна заходити у веб-інтерфейс:

https://192.168.1.180:10000

Для ftp я використаю pure-ftpd. Створюю публічну папку:

sudo mkdir /mnt/data/public

Установлюю pure-ftpd з репозиторія:

sudo apt-get install pure-ftpd

У принципі можна вже заходити під системним аккаунтом, але це не зовсім добре для повсякденного використання. Зроблю віртуальний аккаунт із доступом тільки до публічної папки:

sudo pure-pw useradd public -u local -g nogroup -d /mnt/data/public

Обновлю базу даних:

sudo pure-pw mkdb

Включу використання віртуальних користувачів:

sudo ln -s /etc/pure-ftpd/conf/PureDB /etc/pure-ftpd/auth/50pure

Перезапускаю сервіс:

sudo service pure-ftpd restart

Налаштування доступу до сервера з windows-машин робиться командою:

sudo useradd -d /home/PaulZi -s /bin/true -g users PaulZi

Задаю пароль, такий же, як на windows:

sudo passwd PaulZi

Додаємо створеного користувача до Samba:

sudo smbpasswd -a PaulZi

Для керування розширеними правами, можна встановити утиліти:

sudo apt-get install acl > sudo apt-get install attr

Для того, щоб samba працювала з ACL, необхідна файлова система з підтримкою POSIX ACL, ext4 цілком підходить, але за замовчуванням вона встановлена без цієї підтримки. Для включення цієї можливості додамю опцію «acl» у файл /etc/fstab. Але більше того, в Windows реалізована підтримка спадкування прав, щоб і це реалізувати в linux, потрібно щоб samba десь зберігала додаткові дані. Для цього необхідно включити розширені атрибути файлів, опція «user_xattr». Заодно треба заборонити виконання файлів на всьому розділі з даними, за допомогою опції «noexec» (для безпеки):

sudo nano /etc/fstab/dev/md0 /mnt/data ext4 defaults,noexec,acl,user_xattr 0 2

Перезавантажую операційну систему:

sudo shutdown -r now

Редагую налаштування samba:

sudo nano /etc/samba/smb.conf

Вміст повинен бути згідно лістингу 1.5.

Лістинг 1.5 - Вміст конфігураційного файлу програми Samba

[global] workgroup = Home netbios name = Server security = user # add settings admin users = PaulZi # дія цих користувачів будуть вироблятися від root map acl inherit = yes # включаємо спадкування acl store dos attributes = yes # включаємо зберігання dos атрибутів # відключаємо зберігання windows атрибутів: map archive = no map system = no map hidden = no map readonly = no # public share [public] comment = Public path = /mnt/data/public browseable = yes # кулі видна read only = no # включаємо можливість запису guest ok = yes # дозволяємо гостьовий доступ inherit permissions = yes # включаємо спадкування прав inherit acls = yes # включаємо спадкування windows-прав inherit owner = yes # включаємо спадкування власника hide unreadable = yes # ховати файли недоступні для читання

Перезапускаю сервіс:

sudo service smbd restart

Після перезавантаження сервера, усі установлені компоненти стануть готовими для роботи.

1.7 Алгоритм модуля гео-ІР

Геотаргетинг -- у веб-розробці та інтернет-маркетингу, метод видачі відвідувачеві вмісту, що відповідає його географічному положенню.

Регіональна прив'язка дозволяє сайту перебудовувати контент для різних регіонів. Наприклад, Google використає регіональну прив'язку для перенаправлення користувачів www.google.com у спеціальні домени окремих країн, і така підміна по IP уважається цілком припустимою практикою.

Бізнесом-метою геотаргетингу є таргетирування рекламних й інформаційних повідомлень на релевантну аудиторію. Ефект такої реклами різко підвищується, відповідно, і ціна її значно вище.

Загальною метою геотаргетингу є створення найбільш дружньому користувачеві інтерфейсу й вмісту.

Для зареєстрованих відвідувачів геотаргетинг може здійснюватися опираючись на інформацію, безпосередньо уведену користувачем при реєстрації свого облікового запису (повна або часткова адреса).

Для незареєстрованних відвідувачів вихідні дані для геотаргетингу визначаються на основі регіональної приналежності його IP-адреси.

Геотаргетинг або регіональна прив'язка в мережі дуже схожий на клоакинг, оскільки надає різний контент залежно від типу відвідувача, але в цьому випадку розмежування виконується по територіальній ознаці. Пошукові роботи не розглядаються якось інакше в порівнянні з людьми-відвідувачами. Ця техніка успішно використається, наприклад, коли потрібно показувати різний контент користувачам з різних регіонів.

Реалізація регіональної прив'язки мало відрізняється від реалізації маскування. Маскування і регіональна прив'язка звичайно реалізуються за допомогою однієї й тієї ж техніки -- підміни по IP.

Процес встановлення геолокації на PHP.

Для початку завантажую базу країн (у пакеті geoip-database), міст, модуль для php і встановлюємо їх у систему. Використається база MaxMind.

sudo apt-get install geoip-database libgeoip-dev php5-geoip

wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz

gunzip GeoLiteCity.dat.gz

Створюю нову папку.

sudo mkdir -v /usr/share/GeoIP

sudomv-vGeoLiteCity.dat/usr/share/GeoIP/GeoIPCity.dat

Перевіряю, щоб розширення php було підключено (/etc/php5/fpm/conf.d) і перезавантажую інтерпретатор

sudo service php5-fpm restart

Довідатися код країни можна за допомогою цієї команди:

$country_code = geoip_record_by_name($_SERVER['REMOTE_ADDR']);

Також є багато інших цікавих функцій цього розширення.

- geoip_continent_code_by_name - Одержати двухбуквенный код континенту

- geoip_country_code_by_name - Одержати двухбуквенный код країни

- geoip_country_code3_by_name - Одержати трибуквений код країни

- geoip_country_name_by_name - Возаращает повна назва країни

- geoip_database_info - Одержати версію БД GeoIP

- geoip_db_avail - Перевірити доступність БД GeoIP

- geoip_db_filename - Повертає ім'я файлу БД GeoIP

- geoip_db_get_all_info - Повертає всю інформацію про файли БД у вигляді багатомірного масиву

- geoip_id_by_name - Повертає швидкісну метрику інтернет-каналу користувача (GEOIP_UNKNOWN_SPEED/GEOIP_DIALUP_SPEED/GEOIP_CABLEDSL_SPEED/GEOIP_CORPORATE_SPEED ).

- geoip_isp_by_name - Повертає ім'я провайдера (ISP) користувача

- geoip_org_by_name - Повертає ім'я організації, за якої закріплений IP користувача.

- geoip_record_by_name - Повертає інформацію про місце розташування користувача (континент, країна, місто, широта й довгота).

- geoip_region_by_name - Повертає код країни й регіону

- geoip_region_name_by_code - Повертає назва регіону країни й код регіону

- geoip_time_zone_by_country_and_region - Повертає годинний пояс клієнта (по обчисленій країні й регіону).

Також є різні додатки із базами даних, які можна використати.

1.7.1 Встановлення додатку django-geoip

Процес встановлення модуля гео ІР має певну послідовність, якої необхідно дотримуватися при встановленні. Я використаю додаток django-geoip.

Ця програма працює з python 2.6-2.7, 3.2-3.3, Django 1.3 та старшими версіями.

Рекомендований спосіб встановлення саме через pip, командою:

pip install django-geoip

Додати

INSTALLED_APPS = (...

'django_geoip',

)

Створити таблиці додатків в базі даних:

python manage.py syncdb

python manage.py migrate

Для того, щоб отримати останні дані необхідно виконати виявлення GeoIP, запустивши команду управління:

python manage.py geoip_update

Для розширених налаштувань треба виконати:

MIDDLEWARE_CLASSES = (...

'django_geoip.middleware.LocationMiddleware',

)

Вказую модель в налаштуваннях:

GEOIP_LOCATION_MODEL = 'example.models.Location' # just an example, replace with your own

Вмикаю додаток URL-адреси у схемі URL, для того, щоб відвідувачі могли змінити їх розташування.

Для цього треба виконати команду:

urlpatterns += patterns('',

(r'^geoip/', include('django_geoip.urls')),

)

Особливості реалізації django-geoip. Додаток django-geoip підтримує ієрархію географії Країна -- Область -- Місто, що зберігається в нормалізованому виді в СУБД. Дані по діапазонах IP-адрес зі зв'язками до всіх елементів географії -- у четвертій таблиці. Поточна версія працює тільки з даними ipgeobase.ru, це майже тисяча міст Росії й України й 150 тисяч IP-діапазонів.

Однієї із причин зберігання даних у БД є потреба в створенні своєї моделі географії, що відповідає завданням бізнесу-логіки. Наприклад, в одному із проектів ми обмежуємо визначення локації користувача областями Росії, в іншому -- набором міст, у яких є присутнім компанія. Ця модель реалізує паттерн «фасаду» до ієрархії географії ipgeobase, дозволяючи гнучко настроїти геолокацию під себе.

Наш сайт має кілька регіональних «версій», кожна з яких може містити свій контент. При цьому регіон може мати довільне ім'я й, приміром, містити кілька областей (таблиця geo_location на схемі):



Рисунок 1.1 - Принцип роботи django-geoip

Визначимо свою модель географії MyCustomLocation, та як це приведено в лістингу 1.6.

Лістинг 1.6 - Налаштування моделі географії

class MyCustomLocation(GeoLocationFacade):

name = models.CharField(max_length=100)

region = models.OneToOneField(Region, related_name='my_custom_location')

is_default = models.BooleanField(default=False)

@classmethod

def get_by_ip_range(cls, ip_range):

return ip_range.region.geo_location

@classmethod

def get_default_location(cls):

return cls.objects.get(is_default=True)

@classmethod

def get_available_locations(cls):

return cls.objects.all()

class Meta:

db_table = 'geo_location'

Це звичайна джанго-модель, доповнена трьома классметодами, що реалізують “інтерфейс” фасаду GeoIP. Призначення кожної функції зрозуміло з назви й докстринга. Залишилося заповнити базу назвами міст і прив'язати їх до моделей djagno-geoip.

Прописуємо в settings:

GEOIP_LOCATION_MODEL = 'geo.models.MyCustomLocation'

Добавляємо middleware для автоматичного визначення регіону:

MIDDLEWARE_CLASSES = (...

'django_geoip.middleware.LocationMiddleware',

)

Після таких змін request.location тепер містить значення нашої моделі MyCustomLocation для кожного користувача.

def my_view(request):

context['location'] = request.location

Якщо користувач не виявився в жодному із цих міст, йому буде привласнений регіон по-умовчанню (get_default_location).

Даний підхід сильно полегшує завдання створення «регіональних» сайтів, що відрізняються друг від друга вмістом залежно від місця розташування користувача.

1.7.2 Функція перенаправлення посилань

Тепер, коли можна визначити, звідки прийшов на сайт користувач, його можна пере направити на потрібний сайт. Для цього використаємо переадресацію, яку ще називають - редіректом.

URL redirection, або URL переадресація (також називається як URL пересилання і схожа на техніку перенаправлення домена) -- метод World Wide Web для створення веб-сторінки що доступна за багатьма URL.

Є кілька причин для того, щоб використовувати URL перенаправлення:

Подібні доменні імена, тобто, якщо користувач веб-браузера може неправильного ввести URL, наприклад, "exampel.com" і "exmaple.com". Реєстр організацій часто реєструють подібні домени і направляють їх на «правильне» місце знаходження: example.com. Наприклад: адреси example.com та example.net можуть перенаправити на один домен чи веб-сторінку, наприклад example.org. Цей метод часто використовується для створення «резерву» доменів верхнього рівня з тією ж назвою, або щоб перенаправляти .edu або .net на більш впізнаваний .com домен.

Переїзд сайту на новий домен, а саме, коли веб-сторінки можуть бути перенаправлені в силу декількох причин:

- Веб-сайту, можливо, потрібно змінити доменне ім'я. Для збереження трафіку використовують 300-ті редіректи

- Автор, можливо має намір перемістити на новий домен.

- Два веб-сайти потрібно об'єднати.

Статус-коди редіректів приведено в лістингу 1.7.

Лістинг 1.7 - Коди редіректу

"300" Multiple Choices (кілька варіантів на вибір)

"301" Moved Permanently (переміщено назавжди)

"302" Temporary Redirect (тимчасовий редирект)

"303" See Other (викликаний ресурс можна знайти по ін. адресі)

"304" Not Modified (уміст не змінювався - це можуть бути малюнки, таблиці стилів і т.п.)

"305" Use Proxy (доступ повинен здійснюватися через прокси)

"306" (Unused) (не використається)

Редірект можна зробити двома способами: засобами php та налаштуваннями в файлі htaccess.

Розглянемо два приклади, адже можна використати різні принципи на різних кластерах.

Редірект на php робиться функцією header, яка дозволяє не тільки підмінювати стандартні заголовки, але й додавати нові.

Для редіректу на php можна використкти функцію header - з добавленням заголовка Location або Refresh.

Приклад:

void header ( string string [, bool replace = true [, int http_response_code]] );

Перший параметр string - повністю сформований рядок заголовка, якому необхідно додати (без завершального перекладу рядка "\n")

Другий параметр replace указує, потрібно чи заміняти заголовки з однаковими іменами (true), або ж додавати в кінець (false).

Параметр http_response_code указує код http-відповіді (300, 301, 302 і т.д.).

Ще приклади пере направлення представлені в лістингу 1.8.

Лістинг 1.8 - Коди для перенаправлення

header( 'Location: http://yandex.ru/yandsearch?text=redirect', true, 301 );

header( 'Location: http://google.ru/search?q=redirect' );

header( 'Location: /article/page.htm', true, 303 );

header( 'Location: /', true, 307 );

header( 'Refresh: 5; url=http://rambler.ru/' );

header( 'Refresh: 0; url=/error404.html' );

Це самі найпопулярні способи переадресації засобами php.

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

htaccess - це спеціальний файл веб-сервера Apache, у якому записані інструкції для керування поводженням сервера в цій папці, і у всіх вкладених (якщо в них відсутні свої .htaccess).

Для здійснення редіректа в. htaccess, можна використати кожну із трьох директив Apache: Redirect, RedirectMatch, або RewriteRule(при включеному RewriteEngine).

Приклад:

Redirect [status] URL-path URL-to-redirect

Необов'язковий параметр status - це три цифри - 3хх код редиректу. Якщо не зазначений, то за замовчуванням підставляється 302.

URL-path - частина запитуваного користувачем (або розвідувачем) адреси, що повинна обов'язково починатися зі слеша (/).

URL-to-redirect - повна адреса сайту (і, можливо, частина шляху), на який буде осуществлятся редирект. Повинен бути виду http://site.ru/ - тобто обов'язково повинен бути присутнім протокол (http://) і закриваюча адреса сайту слеш (/).

Якщо URL-path закінчується не слешем, то редирект буде спрацьовувати тільки у випадку точного збігу запитаного користувачем адреси й URL-path.

Якщо URL-path закінчується слешем, то редирект спрацює не тільки для зазначеної адреси, але й для всіх, які починаються на зазначений. А до URL-to-redirect буде додана частина адреси, що випливає за останнім зазначеним слешем в URL-path.

RedirectMatch [status] URL-regexp URL-to-redirect

Дія директиви RedirectMatch аналогічно Redirect, але в параметрах URL-regexp й URL-to-redirect можна використати регулярні вираження.

RewriteEngine on

RewriteRule URL-regexp URL-to-redirect [L,R[=status]]

У директиви RewriteRule більше широкий спектр застосування. Який, у числі інших можливостей, дозволяє її використання й для редиректа - із вказівкою наприкінці рядка у квадратних дужках [ ] прапорів L (виконати негайно) і R (редирект).

Приклади подані в лістингу 1.9.

Лістинг 1.9 - Приклади редіректу

Redirect / http://yandex.ru/yandsearch?text=//302 редірект

Redirect 301 /hello.html http://google.ru/search?q=bye // 301 редірект

RedirectMatch (.*)\.jpg$ http://хостинг_для_картинок$1.jpg //302 редирект

RewriteEngine on

RewriteRule (.*)\.jpg$ http://хостинг_для_картинок$1.jpg [L,R]

Це самі найпопулярніші варіанти використання редіректу, використовуючи файл htaccess.

1.7.3 Статистика

Статистика сайту - це збір й аналіз інформації про його відвідувачів, а також їхня активність. Завдяки статистиці, можна збільшити рейтинг і відвідуваність сайту. Статистика дозволяє визначити WEB-аудиторію відвідувачів, з її допомогою власникові буде легше розвивати свій WEB-сайт.

Функціональність:

- кількість хітів для кожної сторінки;

- хости й хіти в окремо взятий день, а також за періоди;

- статистика браузерів і систем відвідувачів;

- статистика ip-адрес відвідувачів, з можливістю бана;

- статистика пошукових роботів;

- статистика пошукових запитів;

- статистика адрес, з яких перейшов відвідувач;

- бан по IP-адресі.

Є можливість вивести результати на лічильники-картинки кількість хостов і хітів за поточний день, для цього необхідно, щоб на сервері була встановлена бібліотека по роботі із зображеннями GDlib. Є сторінка, яка генерує графік відвідування за останні 30 днів. Подивитися її можна по її посиланню.

Для встановлення системи потрібно розпакувати архів у корінь сайту, і підключити файл count.php у ті сторінки, які треба, щоб вони брали участь у зборі статистики.

Код для підключення лічильника показаний у лістингу 1.10.

Лістинг 1.10 -- Код для підключення лічильника

<?php

$title = "Головна сторінка"; // назва сторінки

$path = ""; // шлях до кореневого каталогу

include($path."count.php"); // підключення файлу

?>

Код для висновку лічильника-картинки показаний у лістингу 1.11.

Лістинг 1.11 - Код для лічильника-картинки

<?php

echo "<img align=left src=".$path."data/img/cntimg.php border=0>";

?>

Після цих простих дій статистика стане доступною і можна буде відслідковувати звідки і коли сайт відвідали потенційні і реальні клієнти компанії ЄвроТрансПошта.

1.8 Система керування базою даних основного кластера

Система керування базами даних (СКБД) -- комп'ютерна програма чи комплекс програм, що забезпечує користувачам можливість створення, збереження, оновлення, пошук інформації та контролю доступу в базах даних.

Першим поколінням СКБД прийнято вважати ієрархічні й мережеві системи. Ці системи отримали широке поширення в 1970-х роках, а першою комерційною системою цього типу була система IMS компанії IBM.

Основні характеристики СКБД:

- контроль за надлишковістю даних;

- несуперечливість даних;

- підтримка цілісності бази даних (коректність та несуперечливість);

- цілісність описується за допомогою обмежень;

- незалежність прикладних програм від даних;

- спільне використання даних;

- підвищений рівень безпеки.

Можливості СКБД є розширеними. Наприклад, дозволяється створювати БД (здійснюється за допомогою мови визначення даних DDL (Data Definition Language)). Дозволяється додавання, оновлення, видалення та читання інформації з БД (за допомогою мови маніпулювання даними DML, яку часто називають мовою запитів).

Також можна надавати контрольований доступ до БД за допомогою:

- системи забезпечення захисту, яка запобігає несанкціонованому доступу до БД;

- системи керування паралельною роботою прикладних програм, яка контролює процеси спільного доступу до БД;

- система відновлення -- дозволяє відновлювати БД до попереднього несуперечливого стану, що був порушений в результаті збою апаратного або програмного забезпечення.

Основні компоненти середовища СКБД:

- апаратне забезпечення;

- програмне забезпечення;

- дані;

- процедури -- інструкції та правила, які повинні враховуватись при проектуванні та використанні БД;

- користувачі;

- адміністратори даних (керування даними, проектування БД, розробка алгоритмів, процедур) та БД (фізичне проектування, відповідальність за безпеку та цілісність даних);

- розробники БД;

- прикладні програмісти;

- кінцеві користувачі.

Архітектура СКБД є трирівневою. А саме, існує система організації СКБД ANSI-SPARC, при якій існує незалежний рівень для ізоляції програми від особливостей представлення даних на нижчому рівні.

Зовнішній -- представлення БД з точки зору користувача.

Концептуальний -- узагальнене представлення БД, описує які дані зберігаються в БД і зв'язки між ними. Підтримує зовнішні представлення, підтримується внутрішнім рівнем.

Внутрішній -- фізичне представлення БД в комп'ютері.

Також є логічна та фізична незалежність.

Логічна незалежність -- повна захищеність зовнішніх моделей від змін, що вносяться в концептуальну модель.

Фізична незалежність -- захищеність концептуальної моделі від змін, які вносяться у внутрішню модель.

У даний момент найбільш відомими ідеологіями побудови паралельних кластерных СУБД є:

- «З поділюваними дисками» (shared disk - SD). Випадок, коли СУБД, що розташовується на декількох комп'ютерах, використає ті самі пристрої зберігання. Цей принцип показано на рисунку 1.2.

Рис. 1.2 -- СУБД з поділюваними дисками

- «З поділюваною пам'яттю» (shared memory - SM). У цьому випадку багато процесорів у СУБД, можливо, розташованих на різних машинах, використають загальну (поділювану) пам'ять, так як це показано на рисунку 1.3.

Рис. 1.3 -- СУБД з поділюваною пам'яттю

- «Нічого загального» (shared nothing - SN).

Ні пристрою зберігання, ні пам'ять таких систем не розділяються. У таких системах кожен вузол обслуговує свій фрагмент БД, унікальність якого забезпечується або організацією БД, або додатковими засобами керування й моніторингу СУБД.

Shared everything є випадком симбіозу SM+SD, коли СУБД використає й загальні пристрої вводу-висновку, і пам'ять, зветься shared everything (SE - «все загальне»). До таких систем, саме, ставиться Oracle RAC, який зображений на рисунку 1.4.

Рисунок 1.4 -- Oracle RAC

Такі системи повинні мати високошвидкісний зв'язок між вузлами для забезпечення роботи з поділюваною пам'яттю, а також якими-небудь засобами спільного доступу до пристроїв зберігання - кластерная файлова система, менеджер пристроїв зберігання й т.п. Достоїнства тут очевидні - це сполучення паралельної обробки, масштабованості й високої отказоустойчивости системи.

Реплікація БД є дуже важливою. Вона забезпечується опцією «High Availability and Disaster Recovery» (HADR). Ця опція входить до складу найбільш повного пакета СУБД DB2 ESE і не входить в інші дистрибутиви продукту.

HADR дозволяє створити репліку основної бази, що буде перебувати в стані «гарячого резерву» стосовно основної бази.

У штатному режимі вся взаємодія здійснюється з основний БД. При цьому до резервної бази застосовуються всі зміни, які були відбиті в журналах транзакцій основної бази.

Запити надходять до основного БД, записуються там у журнали транзакцій і посилають на резервну БД, де теж записуються у файли журналів. Основна й резервна бази взаємодіють на рівні TCP/IP. Це дає можливість розносити системи з основний і резервної БД територіально. Хоча для резервної БД принципово можливо застосування більше простій і менш швидкодіючої системи, IBM рекомендує використати й для основного, і для резервного варіантів БД аналогічні системи. Існує три режими реплікації між основною й резервної БД.

Синхронний режим (SYNC Mode). Цей режим характеризується найвищою надійністю й доступністю й найвищим часом виконання транзакцій. Користувальницькі транзакції обов'язково повинні записатися у файли журналів на основний і на резервної системах. Тільки після цього запис транзакції вважається успішною. Очевидно, що у випадку аварії на основний БД, резервна база в будь-якій ситуації буде повністю відбивати стан основний БД до аварії. Цей спосіб повністю виключає втрату даних. Він зображений на рисунку 1.5.

Рисунок 1.5 - Кластеризація вузлів

Синхронізація файлів і вмісту БД MySQL з територіального сервера на головний сервер. [исправить]

За синхронізацію даних MySQL відповідає mysql replication, дані синхронізуються з головного сервера на територіальні.

Робимо на майстру в my.cnf додаємо рядки:

log-bin = /var/log/mysql/mysql-bin.log

binlog-do-db=databasename

server-id=1

перезавантажуємо MySQL, додаємо користувача для реплікації:

GRANT ALL PRIVILEGES ON databasename.* TO 'slave_user'@'%' IDENTIFIED BY 'slave_password';

FLUSH PRIVILEGES;

далі виконуємо команду:

USE databasename;

FLUSH TABLES WITH READ LOCK;

SHOW MASTER STATUS;

і висновок цієї команди для нас важливий, треба його куди-небудь записати:

| File | Position | Binlog_do_db | Binlog_ignore_db |

| mysql-bin.001 | 10 | databasename | |

тепер робимо дамп бази:

mysqldump -u slave_user -pslave_password -іopt databasename > databasename.dump

і нарешті забираємо лок з бази в MySQL:

UNLOCK TABLES;

Тепер на територіальному сервері:

Створюємо базу:

mysqladmin create databasename -p

Відновляюмо базу з дампа:

mysql -u slave_user -pslave_password databasename < databasename.dump

в my.cnf додаємо рядка такого змісту, як це описано в лістингу 1. 12.

Лістинг 1.12 - Налаштування файлу my.cnf

server-id=2

master-host=XX.XX.XX.XX # IP адреса майстра-сервера

master-user=slave_user

master-password=slave_password

master-connect-retry=60

replicate-do-db=databasename

перевантажуємо MySQL і додаємо дані із команди, так як це показано в лістингу 1.13.

Лістинг 1.13 - Введення даних в MySQL

SLAVE STOP;

CHANGE MASTER TO MASTER_HOST='XX.XX.XX.XX',

MASTER_USER='slave_user', MASTER_PASSWORD='slave_password',

MASTER_LOG_FILE='mysql-bin.001', MASTER_LOG_POS=10;

START SLAVE;

Налаштування готові.

Для синхронізації даних має сенс використати rsync, дуже цікавий протокол/додаток. Він може синхронізувати інкрементально та зі стиском.

На головному сервері в rsyncd.conf додаємо код, так як це показано в лістингу 1.14.

Лістинг 1.14 - Налаштування конфігураційного файлу rsyncd.conf

read only = yes # щоб уникнути ;-)

hosts allow = YY.YY.YY.YY # IP адреса нашого сервера

[somelabel]

path = /path/to/apllication/folder # де лежить додаток

auth users = replica_user # юзер тільки для реплікації в rsync, не системний користувач

secrets file = /path/to/rsync/rsync.secret # де лежить файл із паролем для replica_user,

на територіальному сервері - команду для синхронізації, можна додати в cron з потрібною періодичністю так як це показано в лістингу 1.15.

Лістинг 1.15 Команда для синхронізації

/path/to/rsync -avz -іexclude-from=/path/to/rsync.exclude \

-іpassword-file /path/to/rsync.secret \

rsync://replica_user@XX.XX.XX.XX:873/somelabel /path/to/application

де, rsync.exclude - файл у якому перераховані, які файли (конкретно або по масці) не синхронізувати rsync.secret - файл із секретним паролем для replica_user ХХ.ХХ.ХХ.ХХ - IP майстра-сервера, 873 - дефолтный порт для демона somelabel - мітка з rsyncd.conf з майстра /path/to/application - шлях куди класти дані.

На цьому налаштування синхронізації завершені.

1.9 Система керування базою даних територіального кластера

Напрямок розвитку інформаційних технологій всі частіше зачіпає кластеризацию або поділ БД по декількох серверах. Причому, якщо раніше кластеризація БД мала на меті, насамперед, створення високонадійної та відмовостійкої системи, те тепер, поряд з вимогами до надійності, все частіше переслідуються мета розподілу навантаження по серверах, підвищення продуктивності й масштабованості систем, створення спеціалізованих інформаційних «грід» (grid) для паралельної обробки баз даних.

Грід -- узгоджене, відкрите і стандартизоване середовище, яке забезпечує гнучкий, безпечний, скоординований розподіл ресурсів у рамках віртуальної організації.

Размещено на http://www.allbest.ru/

Рисунок 1.6 -- Структура територіального кластера

На рисунку 1.6 показаний кластер, який складається з двох вузлів, в якому єдиним засобом обміну інформацією між вузлами є високошвидкісний канал зв'язку. По цьому каналу відбувається обмін повідомленнями, за допомогою яких координується робота вузлів. Цей канал зв'язку може бути або складовою частиною локальної мережі, до якої підключені і інші комп'ютери, які не входять до складу кластера, або спеціалізованим каналом. В останньому випадку один або кілька вузлів кластера можуть бути підключені до локальної або глобальної обчислювальної мережі, і через неї кластер, який виконує роль сервера, може зв'язуватись з віддаленими клієнтами системи. Це не обов'язково, але така структура вузла забезпечує більш високу продуктивність і надійність комплексу.

Альтернативою структури кластера з єдиним каналом зв'язку є спільне використання дискової пам'яті. В цьому випадку канал зв'язку між вузлами кластера, як правило, зберігається, але основний обмін даними між вузлами відбувається через спільну дискову пам'ять. Найбільш доцільно використовувати в ролі такої RAID-системи або інші багатодискові системи з надлишковістю. Це дозволяє забезпечувати високу надійність комплексу, оскільки найбільш слабим її місцем є саме спільна дискова пам'ять.

Піонерами кластерних систем були системи з пасивним резервуванням (passive standby). Такий комплекс складається із двох вузлів, один з яких виконує всю роботу, а другий знаходиться в пасивному резерві на випадок, якщо відмовить працюючий вузол. Для координації роботи активний вузол час від часу посилає пасивному вузлу повідомлення, які засвідчують його працездатність (heartbeat message). Якщо такі повідомлення перестають надходити, пасивний вузол розцінює це як відмова активного вузла і вступає в роботу. Тека конструкція комплексу підвищує його надійність в порівнянні з єдиною машиною, але ніяк не відображається на продуктивності комплексу. Більше того, якщо єдина інформація, яка передається від активного вузла пасивному, - повідомлення про працездатність і в комплексі відсутня можливість звернення вузлів до спільної дискової пам'яті, то пасивний вузол при включенні дублює функції активного вузла, що відмовив, але не володіє даними при поточний стан процесу, який був сформований раніше активним вузлом.

В даний час комплекс з пасивним резервуванням не вважається кластером. Цим терміном зараз прийнято позначати комплекси з множиною працюючих вузлів, які сумісно рішають поставлену задачу. Часто їх називають комплексами з активним вторинним вузлом (active secondary).

1.10 UML-діаграма веб-сайту

Веб-сайт - найчастіше досить складна, багатокомпонентна система. Це проект, що вимагає досить багато сил і часу на його реалізацію. Та перед тим як до цієї реалізації приступитися необхідно спроектувати сайт.

Для проектування технічних систем можуть використатися самі різні мови моделювання. Але найпоширеніший й ефективним є - UML-діаграми

Саме тому, для створення сайту, я використовуватиму UML-діаграми, тому що вони значно спрощують процес розробки сайту.

UML -- уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування. Є невід'ємною частиною уніфікованого процесу розробки програмного забезпечення. UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, називаноїUML-моделлю. UML був створений для визначення, візуалізації, проектування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.

Перша версія (1.0) UML вийшла 13 січня 1997, вона була створена за запитом Object Management Group (OMG) -- організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних. Після обговорення, у вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG. Розробку UML підтримали і вже тоді використовували як стандарт такі гранди ринку інформаційних технологій, як Microsoft, IBM, Hewlett-Packard, Oracle, DEC, Sybase, Logic Works й інші.