Самое интересное, что не только в Москве такой бред: adomainforlondon.org.uk/ — официальный ресурс домена Лондона (LONDON); dothamburg.de/ — официальный ресурс домена Гамбурга (HAMBURG); dotberlin.com/ — официальный ресурс домена Берлина (BERLIN); connectingnyc.org/ — официальный ресурс домена Нью-Йорка (NYC); www.dotparis.net/ — официальный ресурс домена Парижа (PARIS).
Идею ICAAN по каждому чиху регистрировать новый домен верхнего уровня не поддерживаю и всячески осуждаю. Текущая древовидная система географически распределенных доменных имен (gTLD) куда более понятная и логичная: нужен домен для города — заведите его поддоменом к стране: msk.ru, odessa.ua и т.д. А так только путаницу разводить. Придется компанию регистрировать в куче зон: company.ru, company.msk.ru, компания.рф, компания.москва, company.moscow, и все только для того, чтобы чуть-чуть защитить название своей компании от киберсквоттеров хотя бы на региональном уровне.
OMG, какие аккумуляторы? Чтобы двигать состав, нужно целый вагон забить аккумуляторами (как в тяговом контактно-аккумуляторном вагоне из «метро 2»). Скорее всего если и были резервные источники питания, так это за пределами поезда (на подстанциях) и напряжение все таки было на контактном рельсе, может даже меньше, чем номинальное. А компрессоры отключены для экономии остатков электроэнергии.
По поводу серверного хозяйства: все довольно тривиально организовано. Пока никаких особо изысканных схем с кластерами, распределенными вычислениями и прочее, да и не нужны они при нынешней нагрузке. К консенсусу пока не пришли, все еще в поисках и в постоянных апдейтах: пробуем различные нововведения, все методом проб и ошибок. Надо еще многое довести до ума, а потом уже статью бабахать. ))
У нас обновления по всем фронтам подоспели. И движок, и системная подложка, и структура серверного хозяйства. Так что скоро все должно быть попроизводительнее, и более отказоустойчиво.
Можете прислать ссылку на описание, как все это работает. Технология интересная, но пока сервера сами неплохо справляются. Как будет затык — будем чего-нибудь придумывать. Можно в личку или сюда, как удобнее будет.
Были, кстати, случаи когда наличие HS-диска спасло ФС: Был сервер у достаточно крупного московского хостера (не буду кидать какашки и тыкать пальцами — такое встречается у многих), на сервере был RAID5 из трех SATA-дисков (сколько я видел дохлых массивов именно на SATA, на SAS я еще ни одного не встречал). А сервер был четырехкорзиночный и один отдельный диск одно время был примаунчен как быстрый архив, но потом он стал не нужен и из него было решено сделать HS. Поводом для такого решения был случай, когда в одном сервере из 5-го рэйда сначала вылетел один диск, контроллер запищал и перешел в degrade-режим. Никто этого особо не заметил, ибо диски в этом сервере использовались не очень активно и просадка по скорости была незначительна. Да, сервер пищал, но хостеру на это было пофигу, ибо и так в гермозоне достаточно шумно и поддержке как-то наплевать и лень искать, что пищит. Я так понял, что пищал у них не один сервер. После того, как рэйд поработал в этом режиме с полгода, вылетел второй диск и… Остались смутные и отрывистые воспоминания о долгих разбирательствах, попытках что-то сделать с массивом, вернее с тем, что от него осталось, поездках по московским пробкам в поисках подходящих дисков и, к счастью, успешной победой разума над бездушной машиной.
После этого я стал искать что-либо такое, что можно поставить на FreeBSD от производителя контроллера, чтобы диски подыхали не в тихую, а с шумом и письмами, по результатам сильно-сильно захотелось кинуть горку какашек и адаптеку и LSI-Logic'у за их убогие cli-утилиты. У 3Ware (AMCC) тоже не шибко хорошая утилита, но хотя бы логичная и нормально работает. Также, решили, что наличие HS-диска тоже неплохая превентивная мера и она в будущем себя окупила на двух серверах точно.
Мораль такова: будь у вас рэйд хоть с мегаизбыточностью, надо вовремя заметить выход дисков из строя. Кстати, у одного хостера я видел дедики, у которых web-application для RAID был встроен в IPMI и можно было тупо вписать в соответствующее поле свой e-mail и туда приходят алерты о всех изменениях статуса массивов. Вот это я считаю круто, ибо не зависит от ОС никак и не надо искать жуткий софт от производителей контроллера и пытаться его настроить.
adomainforlondon.org.uk/ — официальный ресурс домена Лондона (LONDON);
dothamburg.de/ — официальный ресурс домена Гамбурга (HAMBURG);
dotberlin.com/ — официальный ресурс домена Берлина (BERLIN);
connectingnyc.org/ — официальный ресурс домена Нью-Йорка (NYC);
www.dotparis.net/ — официальный ресурс домена Парижа (PARIS).
Идею ICAAN по каждому чиху регистрировать новый домен верхнего уровня не поддерживаю и всячески осуждаю. Текущая древовидная система географически распределенных доменных имен (gTLD) куда более понятная и логичная: нужен домен для города — заведите его поддоменом к стране: msk.ru, odessa.ua и т.д. А так только путаницу разводить. Придется компанию регистрировать в куче зон: company.ru, company.msk.ru, компания.рф, компания.москва, company.moscow, и все только для того, чтобы чуть-чуть защитить название своей компании от киберсквоттеров хотя бы на региональном уровне.
Скайлинк, на сколько я знаю работает на частоте 450МГц (наследие NMT-450i)
Были, кстати, случаи когда наличие HS-диска спасло ФС: Был сервер у достаточно крупного московского хостера (не буду кидать какашки и тыкать пальцами — такое встречается у многих), на сервере был RAID5 из трех SATA-дисков (сколько я видел дохлых массивов именно на SATA, на SAS я еще ни одного не встречал). А сервер был четырехкорзиночный и один отдельный диск одно время был примаунчен как быстрый архив, но потом он стал не нужен и из него было решено сделать HS. Поводом для такого решения был случай, когда в одном сервере из 5-го рэйда сначала вылетел один диск, контроллер запищал и перешел в degrade-режим. Никто этого особо не заметил, ибо диски в этом сервере использовались не очень активно и просадка по скорости была незначительна. Да, сервер пищал, но хостеру на это было пофигу, ибо и так в гермозоне достаточно шумно и поддержке как-то наплевать и лень искать, что пищит. Я так понял, что пищал у них не один сервер. После того, как рэйд поработал в этом режиме с полгода, вылетел второй диск и… Остались смутные и отрывистые воспоминания о долгих разбирательствах, попытках что-то сделать с массивом, вернее с тем, что от него осталось, поездках по московским пробкам в поисках подходящих дисков и, к счастью, успешной победой разума над бездушной машиной.
После этого я стал искать что-либо такое, что можно поставить на FreeBSD от производителя контроллера, чтобы диски подыхали не в тихую, а с шумом и письмами, по результатам сильно-сильно захотелось кинуть горку какашек и адаптеку и LSI-Logic'у за их убогие cli-утилиты. У 3Ware (AMCC) тоже не шибко хорошая утилита, но хотя бы логичная и нормально работает. Также, решили, что наличие HS-диска тоже неплохая превентивная мера и она в будущем себя окупила на двух серверах точно.
Мораль такова: будь у вас рэйд хоть с мегаизбыточностью, надо вовремя заметить выход дисков из строя. Кстати, у одного хостера я видел дедики, у которых web-application для RAID был встроен в IPMI и можно было тупо вписать в соответствующее поле свой e-mail и туда приходят алерты о всех изменениях статуса массивов. Вот это я считаю круто, ибо не зависит от ОС никак и не надо искать жуткий софт от производителей контроллера и пытаться его настроить.