Добавлю, если писать требуется чаще, чем читать, то делайте раздельные данные, например база на филиал (или отдельные таблицы). Каждый филиал пишет в свои таблицы для записи, основные справочники общие на чтение.
И еще, если вдруг запись изменилась сразу с разных мест, то делайте рапределенные псевдо-транзакции, во все основные таблицы добавьте поле version и увеличивайте его на единицу программно или ставьте таймстемп или просто уникальное число (но не автоинкрементом!). Тогда при объединении данных, просто проверяйте, что version равен у обновленных и старых данных, иначе откатывайте транзакцию и разбирайте руками. Это называется оптимистическими блокировками - https://en.wikipedia.org/wiki/Optimistic_concurren...
Xen наверное хорошо, только вот под него ядро заточенное нужно, а в kvm ванильное работает. Ну и в kvm не только линукс поднять можно, а и уиндоуз и фибсд и солярку и еще кучу всего... Может быть я и ошибаюсь, за развитием xen совсем не слежу, тем более производительность равная.
vbhjy1973: бегло посмотрев саивифи, боюсь, это немного не то, что хочет вопрошающий... Данное решение супер для хотспотов, но никак не для провайдинга интернета в котеджном поселке, если этот поселок не гостиница.
Скорее всего wifi просто будет продолжением проводной линии, и по коттеджу будут провода и розетки, если это жилой коттедж. Тогда пользователь умрет каждый раз авторизовываться. При этом скорее всего не решается проблема шейпинга, и возможно, подсчета трафика. Так что в данном случае выделенный биллинг может быть и предпочтительнее. Хотя сама идея saas-биллинга очень даже ничего.
биллин netup www.netup.ru/UTM5/billing.php . на 200 абонентов вполне. нужен будет еще компьютер, на котором будете резать трафик, установите сам биллинг, базу данных, freeradius и прочие пироги, это может быть обычный комп с линуксом, или несколько (под базу, роутер, freeradius, биллинг и т.д.).
Neabramovich: Есть еще разные кодеры, например darkice, берет аудио со звуковой карточки (alsa, oss)^ а также с jackaudio, pulseaudio, кодирует (flac,aac,mp3...) и публикует на icecast например.
Neabramovich: Стриминг аудио с телефона как взять не знаю, но похоже в этом случае нужен DNLA клиент, который возьмет аудио и направит его например через pulseaudio в mpd или куда-то еще. Вы же полностью что хочется, не рассказали...
mpd это сервер audio, на телефоне у вас тоже сервер, но dnla. А вам нужен клиент какой-то.. Для mpd есть консольный mpdc и еще кучу разных. с dnla не возился.
Можно еще установить сервер вещания, их много есть, начиная с icecast (протокол showcast) и заканчивая nginx rtmp (flash/hls и еще куча)
Будет создано два зеркала (radi1) по два диска и эти зеркала будут слиты страйпе (raid0). Общая емкость - 4/2 = 2.
Тоже самое и на аппаратном рейде. Нынешние контроллеры, конечно умные и с батарейками, но общая производительность будет как raid1 на два диска.
Я не против аппаратных raid-контроллеров, но по мне, они не нужны. Сгорел контроллер - пиши пропало, и через год можно уже не найти аналогичный.
Если уж зашла речь, для чего же эти контроллеры вообще нужны?! Скажу - для SAS!!!! Если у вас нет SAS, и достаточно наплатных SATA разъемов, контроллер не нужен. Никакого прироста скорости против софтварной реализации не получите, хотя ресурсов чуть отожрется у CPU, так и купите на эти деньги лишние CPU!
О! да очень просто. Делаете RMI-сервер. Каждый подключившийся клиент вызывает удаленный метод getJob() например. Удаленный метод (на стороне сервера) дает клиенту следующую строку матрицы (и просто запоминает какую строку дать в следующий раз). Как только строка матрицы посчитана, клиент вызывает sendResult() с результатом для какой строки матрицы и опять запрашивает getJob(). Сервер в методе sendResult смотрит, посчитаны ли все строки матрицы, если посчитаны, то завершает работу!
Соответственно каждый клиент будет получать только свою строку и возвращать немедленно только свой результат, снова запрашивать и так до бесконечности. Тем самым у вас будет от одного до N клиентов.
Абсолютно точно. Одних отпугиваете, другим нужно что-то более конкретное и узкопрофильное. Пишите резюме под конкретную компанию, надеюсь, для вас это не трудно.
Ян Ко: да, бывал, причем печальный. Если raid5, то лобязательно с хотспаре. Лучше, конечно raid10, но не все могут себе его позволить. Софтверный лучше восстанавливается. Мы сейчас вообще перешли на hba-адаптеры, все raid делаем в софте. Более того, просто взяли и развернули ceph и ненарадуемся больше года. Есть и скилл восстановления ceph(rbd) из месива, но здесь сами себе были злобные буратины.
Здесь же советую конфигурацию для сервера, который скорее всего будет 1U, а в него более четырех дисков 3,25 не влазит :-(
Что касается горячей замены, то это не привилегия адаптера или контроллера, а привилегия бекплейна, у нас например работает дискокопирка на матьбордовом sata с блоком салазок с горячей заменой, заливаем по 100 дисков раз в месяц, все четко.
И что же предложить для 4-х дисков?! Raid10 расточительно, raid6, на запись оптимизировать нужно, остается raid5 с горячей заменой. Остальное - регулярные бекапы на внешнее хранилище!!! Если воткнуть аппаратный рейд, то на таком количестве дисков разница производительности все равно не будет заметна, проверено не раз.
Ну, да, давайте воткнем 2U с 12-ю дисками, с аппаратным рейдом и увеличим стоимость сервера и размещения в два раза. Хорошее предложение.
Упс, ip-ресиверы конечно... И посмотрите мой ответ, на счет простой програмки на gstreamer. Gstreamer вещает мультикастом сразу на все точки одновременно. Через gstreamer аудиопоток и принимается на концах и выдается в линейный аудио выход. Другими словами, есть один комп-передатчик и куча компов-приемников, синхронизация автоматическая. Можно даже не писать программу! Поставьте везде mpd, вместо gstreamer.. www.musicpd.org
Ух, оптику варят, пригласите сварщика и он все сделает, или сразу закажите с разъемами на концах. Медиаконвертеры и оптика сделает вам линию ethernet в 600 метров. Далее или сами через компы мультикастом или через ip-расиверы. Я же не знаю ваш бюджет, можно дорого и красиво, а можно, если умеете программировать, на расберри пи. Вариантов масса..