iOS 7 на iPhone

Внешний вид непривычный, на первый взгляднеобтесанный в сравнеии с предыдущим.
Есть некоторые приятные функции вроде быстрого доступа к включению/выключению WiFi и автономного режима. Но версия еще сырая. В частности некоторые части интерфейса не переведены на руссий. Я заметил:
1. AppStore, причем не только интерфейс приложения, но и описания программ выдаются на английском, как будто неправильно системная локаль установлена
2. Слетел язык голосового управления, надо поменять обратно на русский в настройках.

UPDATE.
По поводу appstore, оказывается сам AppStore переведен, но у меня аппарат оказался привезенным из США и AppStore решил что аккаунт у меня тоже из США.
Выяснилось это когда я попытался обновить приложение и получил ошибку:
Your account is not valid for use in the U.S. Store. You must switch to yyy Store before purchasing.
Путь изменения страны AppStore оказался неочевидным, т.к. никаких настроек кроме того загружать ли приложения автоматом через сотовую есть у него нет.

Инструкцию нашел на http://www.survivalguide4idiots.com/ios-6-bug-your-account-is-not-valid-for-use-in-the-xxx-store-you-must-switch-to-yyy-store-before-purchasing-2.html

1. Запустить AppStore
2. Нажать Feautured в левом нижнем углу
3. Прокрутить экран вниз и нажать на собственном AppID
4. Нажать View
5. Выбрать правильную страну.

У меня на пункте 4 вылезла ошибка, но аккаунт сам понял что он российский.

Небольшой ceph-кластер в работе

Кластерная система хранения это хорошо, но сначала надо уметь хорошо его готовить. Если падает кластер хранения - падает всё.

Решил сделать отказоустойчивый кластер для хостинга на основе ceph. Система хорошая, готовая к использованию и похоже что используется.
Собрал кластер из трех серверов. Из них два с дисками для хранения, один маломощный просто под монитор (чтобы 3 монитора было).
Погонял тесты, поронял кластер - всё отрабатывает замечательно. При ручных тестах, сбоях, перезагрузках, имитациях зависания диска, тормозов и т.п. кластер работает отлично. Сбои-зависания обнаруживаются в течение от 30 секунд до 2-3 минут, сами чистятся и дисковые операции продолжатся без сбоев.
Запустил на кластере рабочие сайты, запускал по очереди. Когда добавил 4-5 сайтов средней нагрузки пришлось обновиться для добавления еще одного сервера (обновление было небольшим и я решил что это проще, чем вручную ставить старые версии пакетов) и тут началось.

1. Обновления прошли гладко, все узлы обновились без остановки кластера, договорились между собой.
2. Через полчаса один из серверов завис намертво, починился хард-ресетом. Сам кластер жив, продолжает работать как и должен при потере одного сервера.
3. Через несколько часов начались проблемы и замиранием операций ввода-вывода на полчаса (т.е. сайты висят и не открываются, ждут ответа из базы например или чтения php-файла). Прошло само, потом началось снова. Проблема похожа вот на эту и видимо пришла с обновлением, еще раз кувалдой по балде: если работает - не обновляйся.

Документации по ошибкам нет, вообще документация по инструментам и ошибкам довольно скудная и порой даже самые простые вещи получается делать только через эксперимент.

Такие падения в работе неприемлимы, а плюшки ceph очень вкусны для того чтобы сразу от них отказываться - наличие актуальных данных на любом сервере (а не только на двух как при rdbd например).
Настроил программный массив raid1, один диск - rbd образ, второй - локальной блочное устройство из LVM на случай сбоев/падения кластера. Абсолютно не помогло - при зависаниях кластера (для имитации просто выключил все сервера хранения) операции ввода-вывода в md-raid останавливаются, сделать с ним ничего нельзя пока не включить кластер обратно + сервер стал вешаться чуть ли не по щелчку пальцами.

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

Установка Windows server на ISCSI-диск.

Введение

Настраиваю бездисковую загрузку виртуальных машин Hyper-V, в частности Windows-сервер. Диск должен подцепляться загрузчиком по ISCSI, затем подключение передается в Windows и Windows загружается. Устанавливается Windows тем же способом - сначала загрузчик подключается к iSCSI диску, затем происходит загрузка с DVD и винда устанавливается обычным образом. При первых тестах, когда iSCSI-таргет работал на Windows-server, доступ производился по общей сети с нормальным DHCP и публичными IP-адресами. Всё работало.

Проблема

Проблема получилась, когда стал настраивать Linux-storage и отдельную транспортную сеть для iSCSI. iPXE подключается к iSCSI-диску, говорит что всё отлично, установщик Windows загружается и диска не видит.

Причина

Причина оказалась в том, что iSCSI-инициатор, который используется при загрузке (и видимо при установке Windows) ВСЕГДА отправляет пакеты на шлюз по умолчанию, даже если диск находится в той же подсети. Транспортная сеть одноранговая, маршрутизаторов в ней нет и настроек таких DHCP не раздавал. Если бы в сети был шлюз, то весь iSCSI-трафик пошел бы через этот шлюз, а не напрямую к серверу с дисками (нагрузка на сеть увеличивается вдвое, увеличиваются задержки и собственно причина совершенно неочевидна).

Решение

В качестве шлюза по умолчанию назначается IP-адрес сервера, на котором лежат диски, тогда пакеты идут сразу куда нужно, винда видит диск, спокойно на него ставится и с него загружается.