У Сенса один большой недостаток — его просто так совсем не удалить. Если AOSP можно худо-бедно настроить именно так, как хочется, благо модов, лаунчеров и программ всяких миллион, то с сенс все сложнее. Дали конфету — жуйте. Приторно и сладко и пить хочется? Жуйте-жуйте.
У меня как-то наоборот, поставил ICS и больше не могу пользоваться версиями меньше, уже не цепляют. Описанных минусов не заметил, либо за минусы не считаю, может это и фанатизм ))
Разряд при интенсивном использовании идет быстрее, чем заряд по USB. Не знаю, как с остальными устройствами, для андроида нужно что-то помощнее, чем зарядка через USB. Мой нексусС, включенный в USB, с включенным навигатором, садится со 100% за 4-5 часов.
Нативный клиент тоже в userspace и тоже FUSE)) Я не говорю, что это плохо. Плюсов у такого решения много. Но это не всем подходит. NFS, CIFS нам не подходят тоже. Нагрузки слишком велики.
Если не сложно, можно подробней про конфигурацию. С какой целью будет использоваться GlusterFS, что на ней будет лежать?
Мы, к примеру, использовали следующую конфигурацию. Кратенько из серии #мывсеумрем ))
1. БД — два инстанса postgres в master-slave репликации
2. Веб-приложение — два инстанса. Внутри nginx+php-fpm, общий каталог с некоторым количеством кода.
3. Сфинкс+индексатор — два инстанса с общим каталогом индексов,
Веб1 ломится в бд1 и в сфинкс1, веб2-бд2-сфинкс2.
Запускаем нагрузку tsung. Параметры нагрузки такие же, как и в случае использования локальных файловых систем. Получаем дикие тормоза при использовании любой системы, которая FUSE.
— БД начинает мощно забирать ресурсы CPU и I/O,
— всем user level процессам система говорит «подождите чуть-чуть, я пока занята на system level, сейчас закончу, дойдем до вас». Время реакции везде увеличивается, время отклика везде увеличивается
— хранилище замерзает, время доступа к нему возрастает.
— бекенд, который использует разделяемый код, начинает затуплять, 500ые
— сфинксы оба тоже затупляют, увеличивается время ответа сервиса, 500ые
— затупляет бд slave, который тоже быстро хочет актуальных данных. Их нет из-за ресурсов, которые тратят сервисы, пытающиеся достучаться до замершего хранилища. Растет replication lag, веб2 сыпет 500ми, но по-прежнему тратит процессорное время и I/O.
Все разделяемое вроде бы на месте, но очень долго читается, сервисы считают, что ничего не работает.
Ядро со своими планировщиками в панике, начинается чехарда с дикими переключениями контекстов, нелинейно растет load average, затупление приобретает характер снежной лавины ))
Выключаем tsung, все работает стабильно, ничего не потерялось, сервис работоспособен и шустро отдает контент. Страшный сон администратора! )))
Здесь очень сложно все, например с приоритетами по I/O. FUSE не очень хорошо работает под нагрузкой. Если у нас нет ресурсов на юзерлевел, то все встает колом сразу ))
К сожалению, надо патчить ядро. Там итак уже есть OpenVZ, боюсь не осилим прикрутить еще и такую сложную штуку и чтобы работало. Даже не рассматривали из-за этого. Оставим напоследок, спасибо ))
Насколько я помню, это поддерживается из коробки в RedHat Advanced Server and SuSE Enterprise Server. В debian-based дистрибутивах придется поплясать краковяк, гопак и польку сразу, чтобы все заработало )))
a.silenkov@uk-rnd-32:~$ apt-cache search gpfs | wc -l
0
Да и отыскать что-либо вменяемое в документации IBM быстро не получится при случае. Blade center мы, например, неделю запускали, пока 300 листов документации не прочитали, скачав стопицот файлов, прошивок, утилит, так и стоял как кирпич.
permissions, acl, inotify. Безопасность, совместимость с локальными файловыми системами, гибкость.
Понятно, что у специализированных файловых систем совместимость зачастую не полная. Разработчики не должны писать код, заточенный под систему, которую мы предоставляем и который в другой может не заработать.
Также если кластер развалится, придется работать с локальными файловыми системами и хочется не заботиться о совместимости на системном уровне с точки зрения приложения.
Альтернатив мы пока не нашли все равно )))
Мы искали не совсем кластер хранения, если я правильно вас понимаю ) Мы искали возможность множественного монтирования read-write.
Хочется для начала достичь следующего эффекта: кластер жив и все работает хорошо и быстро. Если кластер отказал, все работает по-прежнему, но медленней (в рамках разумного) и ждет администратора, чтобы починил.
Мы пока только экспериментируем и исследуем.
Устойчивость к сбоям — очень важный аспект, несомненно. До него дойдем, чуть позднее только. Тут довольно сложный момент получается. Любую систему можно сделать неустойчивой, все дело в нагрузке на нее. Поэтому мы решили проверить отказоустойчивость (а также пределы по нагрузке) чуть позже, после того, как будет выбран инструмент, подходящий по остальным пунктам.
У нас есть разные задачи, которые будут решены с помощью таких механизмов. Есть и некритичные данные, которые можно потерять без фатальных последствий.
Мы, к примеру, использовали следующую конфигурацию. Кратенько из серии #мывсеумрем ))
1. БД — два инстанса postgres в master-slave репликации
2. Веб-приложение — два инстанса. Внутри nginx+php-fpm, общий каталог с некоторым количеством кода.
3. Сфинкс+индексатор — два инстанса с общим каталогом индексов,
Веб1 ломится в бд1 и в сфинкс1, веб2-бд2-сфинкс2.
Запускаем нагрузку tsung. Параметры нагрузки такие же, как и в случае использования локальных файловых систем. Получаем дикие тормоза при использовании любой системы, которая FUSE.
— БД начинает мощно забирать ресурсы CPU и I/O,
— всем user level процессам система говорит «подождите чуть-чуть, я пока занята на system level, сейчас закончу, дойдем до вас». Время реакции везде увеличивается, время отклика везде увеличивается
— хранилище замерзает, время доступа к нему возрастает.
— бекенд, который использует разделяемый код, начинает затуплять, 500ые
— сфинксы оба тоже затупляют, увеличивается время ответа сервиса, 500ые
— затупляет бд slave, который тоже быстро хочет актуальных данных. Их нет из-за ресурсов, которые тратят сервисы, пытающиеся достучаться до замершего хранилища. Растет replication lag, веб2 сыпет 500ми, но по-прежнему тратит процессорное время и I/O.
Все разделяемое вроде бы на месте, но очень долго читается, сервисы считают, что ничего не работает.
Ядро со своими планировщиками в панике, начинается чехарда с дикими переключениями контекстов, нелинейно растет load average, затупление приобретает характер снежной лавины ))
Выключаем tsung, все работает стабильно, ничего не потерялось, сервис работоспособен и шустро отдает контент. Страшный сон администратора! )))
a.silenkov@uk-rnd-32:~$ apt-cache search gpfs | wc -l
0
Да и отыскать что-либо вменяемое в документации IBM быстро не получится при случае. Blade center мы, например, неделю запускали, пока 300 листов документации не прочитали, скачав стопицот файлов, прошивок, утилит, так и стоял как кирпич.
Понятно, что у специализированных файловых систем совместимость зачастую не полная. Разработчики не должны писать код, заточенный под систему, которую мы предоставляем и который в другой может не заработать.
Также если кластер развалится, придется работать с локальными файловыми системами и хочется не заботиться о совместимости на системном уровне с точки зрения приложения.
Альтернатив мы пока не нашли все равно )))
Хочется для начала достичь следующего эффекта: кластер жив и все работает хорошо и быстро. Если кластер отказал, все работает по-прежнему, но медленней (в рамках разумного) и ждет администратора, чтобы починил.
Устойчивость к сбоям — очень важный аспект, несомненно. До него дойдем, чуть позднее только. Тут довольно сложный момент получается. Любую систему можно сделать неустойчивой, все дело в нагрузке на нее. Поэтому мы решили проверить отказоустойчивость (а также пределы по нагрузке) чуть позже, после того, как будет выбран инструмент, подходящий по остальным пунктам.
У нас есть разные задачи, которые будут решены с помощью таких механизмов. Есть и некритичные данные, которые можно потерять без фатальных последствий.