Если у вас есть возможность перевести БД на один единственный отдельный сервер, то сайт умрет полностью - Администрирование серверов

523

rustelekom

4 марта 2009, 15:15

#31

падает все бесспорно. только для кого я это писал: "другое дело что можно вшить в зону заранее штук 3-10 ай-пи адресов прокси или лод балансеров" :) ?

SSD VPS, SSD хостинг и выделенные серверы в Германии или РФ, FTP хранилища, регистрация доменов и SSL сертификаты ( https://www.robovps.biz/ ) Контакты: Telegram ( https://t.me/rustelekom_bot )

N

419

netwind

4 марта 2009, 15:35

#32

rustelekom, и вы тоже неправильно понимаете смысл технологии. Браузеры cами не умеют перебирать IP. По крайней мере МОГУТ НЕ перебирать, в терминах rfc.

Кнопка вызова админа ()

822

Andreyka

4 марта 2009, 15:57

#33

rustelekom:
через днс это делать нет особого смысла из за кеширования ай-пи.

Имеет

Пусть 50% имеют проблемных провайдеров, которые игнориуют TTL

Тогда в случае проблем сайт сохраняет 50% трафика

Если же этого не сделать, то сайт умрет полностью

Так что лучше 50% чем ничего.

Не стоит плодить сущности без необходимости

N

419

netwind

4 марта 2009, 16:23

#34

Есть еще очень интересные варианты с использованием SRV-записей.

По-моему IE их поддерживает. Если так, то пользователей поболее 50% будет.

На Firefox не работает. На Опере, как обычно, тоже.

JD

471

Jet D.

4 марта 2009, 17:03

#35

rustelekom:
через днс это делать нет особого смысла из за кеширования ай-пи. хоть какой ттл ставьте если провайдер доступа в инет тормоз то он обновит зону с новым ай-пи спустя большое время (явно не через 10 минут - скорее через несколько часов а то и суток).

Проблема игнорирования TTL действительно существует, и мы здесь совсем недавно уже обсуждали это. Но процент "проблемных" посетителей низок. Или у Вас есть другая статистика?

rustelekom:

Но, возникают другие проблемы:

а) синхронизация файлов сайта и особенно синхронизания баз данных (можно отчасти решить выделив базы на отдельный сервер а то и два (аля репликация) к которому подключаются все веб серверы)
б) синхронизация логов и ведение статистики (а вот тут не знаю что можно сделать не видел нигде софта для решения этой проблемы)

В общем случае, выносить БД на один единственный отдельный сервер смысла нет, т.к. это сильно понижает надежность. Вообще это делается в других случаях.

Репликация БД, а тем более, объединение логов не является проблемой. Статистику можно вести даже со стороннего (ну или собственного) сервиса, это и близко нельзя назвать проблемой.

rustelekom:
падает все бесспорно. только для кого я это писал: "другое дело что можно вшить в зону заранее штук 3-10 ай-пи адресов прокси или лод балансеров" :) ?

Пусть используется 3 ip (round-robin), браузер получит только один из них. И в случае падения одного из них, для ~ 33,(3)% посетителей сайт будет недоступен.

Round-robin есть смысл использовать, например для (geo) load balancing, но не нужно путать это с failover, о котором и идет речь.

Лишние прокси и лоад балансеры, при такой схеме, вообще вредны с точки зрения надежности, если только они не могут обеспечить 100% uptime. А если у Вас есть в наличии сервера с гарантированной 100% надежностью и аптаймом, все о чем здесь идет речь, вообще теряет смысл.

Понятно что есть более солидные решения, обеспечивающие надежность и гео-балансинг, в рекламных материалах которых можно встретить упоминание "CDN", "BGP", "Price: $XX,XXX" и даже "Price: $XXX,XXX", но здесь речь идет об экономичных способах добиться high availability.

netwind:
Есть еще очень интересные варианты с использованием SRV-записей.

SRV-записи - штука хорошая, и даже позволяют указывать распределение нагрузки в процентах, но в настоящее время используются только для jabber, sip и подобных сервисов, хотя изначально планировалось перевести на них чуть ли не "весь Интернет".

eTarget 2011:Панельная дискуссия «Стратегия eTarget 2011: Круглый стол Могут ли «плохие» входящие

151

Jake Foley

4 марта 2009, 19:50

#36

Stels71:
Не силен в администрировании, отсюда дилетанский вопрос: возможно ли сдлеать что при обращении на сервер1 по ДНС1.1, 1.2 и не получнии отклика, посетителя перекидывало на зеркало сервера - сервер 2 по ДНС2.1, 2.2. Кроме того, сервер 1 и сервер 2 каким-либо образом синхронизировались?
Есть варианты решения?

Лазил в сети по сайтам бесплатных скриптов и наткнулся вот на что:

Этот скрипт проверяет список зеркал, и автоматически перенаправляет пользователя на первый доступный сайт из списка.

<?php



//******************************************

//* Alpha Download Mirror Search by Visyte *

//******************************************



// Version: 1.0



// Einbinden des ADMS:



// 1. Anzahl der Mirrors unter $NumDL eintragen.

// 2. Entsprechend der Mirroranzahl die Downloadadressen eintragen.

// 3. Das Script Anstelle des bisherigen Download in ihre Seite eintragen.



// Tipp:



// Der Dateiname kann zur besseren Ьbersichtlichkeit umbenannt werden.



//*****************

//* Einstellungen *

//*****************



$NumDL=2; //Anzahl der Mirrors

$DLM[0]="http://"; //Download Mirror 1

$DLM[1]="http://"; //Download Mirror 2

$BgCol="#eeeeee"; //Hintergrundfarbe der Seite

$FontTag="<font size=2 face=arial color=#000000>"; //Schrifteinstellungen



//*************

//* Quelltext *

//*************





echo "<html><head><title>Visyte Alpha Download Mirror Search</title></head><body BgColor=$BgCol>$FontTag ";

for ($i = 0; $i < $NumDL ; $i++)

{

  $Mirror=$DLM[$i];

  $l=$i+1;

  echo "Ьberprьfe Mirror $l...";

  if (eregi("^http://", $Mirror))

  {

   $UA=@parse_url($Mirror);

   if(!$UA[port]) $UA[port]="80";

   if(!$UA[path]) $UA[path]="/";

   $sock=fsockopen($UA[host], $UA[port], &$errnum, &$errstr);

   if(!$sock) 

   {

    $ret="NR";

   }

   else 

   {

    $dump="GET $UA[path] HTTP/1.1\r\nHost: $UA[host]\r\nConnection: close\r\nConnection: close\r\n\r\n";

    fputs($sock, $dump);

    while($str = fgets($sock, 1024))

	{

     if (eregi("^http/[0-9]+.[0-9]+ ([0-9]{3}) [a-z ]*", $str))

	 {

	  $ret=trim(eregi_replace("^http/[0-9]+.[0-9]+ ([0-9]{3}) [a-z ]*", "\\1", $str));               

     }

	} 

    fclose($sock);

    flush();

   }

   $ret2=0;

   switch($ret)

   {

    case NR: echo "Server reagiert nicht";

	         $ret2=1;

			 break;

	case 404: echo "Datei wurde nicht gefunden";

	          $ret2=1;

			  break;		   		 

   }

   if($ret2!=1)

   {

    echo "Done -> <a href=$Mirror>Downloading von Mirror $l</a>";

	echo "<script>self.window.location.href='$Mirror';</script>";

   }

   echo "<br>";

  }

 }

 echo "<br><br>Script @ <a href='http://www.visyte.com'>Visyte</a></font></body></html>";

?>

Почему не сделать вместо зеркал - адрес_сайта1 и на месте второго - адрес_сайта2 в случае неработоспособности первого

eTarget 2011:Панельная дискуссия «Стратегия eTarget 2011: Круглый стол Могут ли «плохие» входящие

181

dex

4 марта 2009, 20:49

#37

Jake Foley:
Лазил в сети по сайтам бесплатных скриптов

ну, эт Вы маханули

а-ля примитивный прокси с ненадежной уверенностью в недоступности и антиреализацией:)

губит людей вода (подпись не продаю, в долг не даю)

N

419

netwind

4 марта 2009, 21:23

#38

Jet D., да, похоже я наврал насчет SRV для эксплорера. Однако ActiveDirectory их во всю использует. Непонятно что их останавливает.

P

250

Pilat

4 марта 2009, 21:28

#39

Jet D.:
Убытки реально бывают и болше, за минуты неработоспособности, поэтому и время простоя в таблице указывать нет смысла. Таблица приведена как пример сайтов, которые хоть и переживут "даун на три дня", но убытки будут огромными. Поэтому они и готовы платить большие деньги, чтобы свести риски недоступности к минимуму.

Касательно половины из перечисленных категорий серверов: висят они преотлично. И банки, и сервисы продажи билетов.

Pilat добавил 05.03.2009 в 00:31

Jet D.:
Понятно что есть более солидные решения, обеспечивающие надежность и гео-балансинг, в рекламных материалах которых можно встретить упоминание "CDN", "BGP", "Price: $XX,XXX" и даже "Price: $XXX,XXX", но здесь речь идет об экономичных способах добиться high availability.

Насчёт BGB золотые слова :) Но на самом деле это и есть один из самых простых способов (и недорогой к тому же) добиться непотопляемости сайта. Стоит себе сервер в автономной сети с десятью каналами - и боится только пропадания напряжения, что бывает редко.

Блог (http://www.pilat66.ru/)

JD

471

Jet D.

4 марта 2009, 23:30

#40

Jake Foley:
Лазил в сети по сайтам бесплатных скриптов и наткнулся вот на что:

Этот примитивный "редирект" не имеет отношения к обсуждаемой теме. Про надежность вообще молчу...

Pilat:
Касательно половины из перечисленных категорий серверов: висят они преотлично. И банки, и сервисы продажи билетов.

Висят. Но как правило, один раз потеряв из-за этого большие деньги, стараются в кратчайшие сроки решить проблему и недопустить в дальнейшем. Бывает, конечно, и по-другому - к примеру, Ассист, не так давно, висел несколько дней под ddos, и было такое впечатление, что им на это просто наплевать. Такое отношение называется, сами знаете как. Но действительно серьезные сервисы мирового масштаба, изначально вкладывают средства в снижение рисков недоступности.

Pilat:

Насчёт BGB золотые слова Но на самом деле это и есть один из самых простых способов (и недорогой к тому же) добиться непотопляемости сайта.
Стоит себе сервер в автономной сети с десятью каналами - и боится только пропадания напряжения, что бывает редко.

Это не спасет от сбоя софта или самого сервера. Да и простота, и низкая цена - это все относительно. Но штука, действительно хорошая :)

Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ

Дзен реализовал для авторов возможность вывода денег через СПБ

Синхронизация серверов бюджетные варианты.