Пользуюсь этим телефон уже два месяца. В коробке присутствует и гарнитура и зарядка (куплено в европе).
Задняя крышка скользкая, неудобно. В остальном очень доволен.
Несколько раз покупал подобные китайские девайсы (но не именно этой марки) — даже низкая стоимость не способна восполнить ущербность железа/прошивки. Наиболее частые слабые места: батарея, чувствительность экрана, gps, etc.
Я ведь написал, что у DD890 только 4 порта, которые уже заняты, интерфейс 10 Гб вставить некуда. Я так же писал в каком конкретном случае лента выигрывает у дисковой системы: большие объемы ежедневного трафика (несколько клонов по 15 То), много клиентов резервного копирования. По экономическим соображениям здесь лента будет выгоднее.
Про дедупликацию сейчас речь не идет. Это тема отдельная, там свои заморочки.
Два клиента могут вполне использовать один и тот же драйвер, естественно они при этом пишут или читают попеременно. Так же как и один клиент может писать на несколько драйверов. У datadomain полоса пропускания одна на всех клиентов — 4х8 Гб/с. У ленты — каждый драйвер со своим контроллером FC.
По поводу масштабируемости дисковых систем можно поспорить. Вы привели цифры лишь о емкости, а как же входяший/исходяший трафик? К примеру, у нас в ДЦ стоит EMC Datadomain 890 у которой максимум 3 порта FC 8Gb/s и больше нет слотов. И стоит лента Quantum Scalar i6000 с 24 LTO5 драйверами FC 4Gb/s (96 драйверов максимум). Получается что для того, чтобы достичь уровня ленточной библиотеки в трафике, нужно несколько DD, стоимость которых зашкаливает. То есть там где нужна реальная масштабируемость и большие объемы резервных копий — лента пока имеет свое место исходя из экономических соображений. Но это скорее частный случай.
А в общем случае, дисковая система выигрывает у ленты так же в силу дополнительного функционала:
— дедупликация
— репликация
— client direct LAN (клиентский сервер может напрямую отправлять данные дисковой системе, без участия медиа-сервера)
Спасибо за решение, пара вопросов по этому поводу:
— почему не записать стандартные, повторяющиеся фразы в формат mp3 или gsm, вместо того чтобы обращаться каждый раз к гуглу (”Здравствуйте! После звукового сигнала произнесите имя абонента”)? Это реально в продакшине или для примера показано?
— какова задержка обработки в обоих случаях: googletts.agi и speech-recog.agi
Да, в сап есть стандартный набор утилит br*tools, который справляется с резервным копированием и достаточен. Но в итоге получается, что кроме сап, в инфраструктуре очень много всего что нужно сохранять — операционки, файлер, exchange какой-нибудь и т.д. И тут встает вопрос о том чтобы иметь единый софт, который бы имел необходимые модули для консистентого резервного копирования различного ПО, мог выдавать понятные отчеты, управлять каталогом копий и при этом имеющий саппорт.
Получается, что проще управлять всей этим через одно, пусть платное решение, чем несколько разрозненных утилит.
P.S. Если существует opensource решение отвечающее этим требованиям — тем лучше, правда я не знаю такое. Подскажите, возьму на заметку.
предположу, что компания которая инвестирует в сап, не поскупится купить проприетарное решение (emc networker, symantec nbu, etc) чтобы иметь гарантированный саппорт.
По моему все правильно. Только вчера сдали пакет документов в ответ на тендер для облачной инфраструктуры. Клиент в своих запросах идет достаточно далеко (100 стр. тех. задания), к вышеуказанным требованием добавлю:
— интеграция его собств. датацентра и облака
— миграция в облако: методы, планировка
— как дать доступ партнерам к облаку по Интернет + ssl
— возможность виртуализации AIX
— можно ли иметь несколько зон в облаке
— патч-менеджмент опер. систем и ПО: какой процесс и периодичность
— может ли оператор разместить у себя в ДЦ особую аппаратуру клиента (riverbed, etc.)
— какие доп. средства может предоставить оператор (scheduler, cmdb, ...)
— а так же много запросов по поводу управления (все что относится к itilv3): роли, обязанности
В итоге такой чек-лист актуален, когда переноситься ИТ-инфраструктура в облако, а не просто два-три сервера.
Нельзя ли собрать FlexPod самому по запчастям? К примеру, часть оборудования уже есть.
Можно, но такая система не будет называться FlexPod.
Будет, по крайней мере это нам обещал Cisco и NetApp. Это и логично, ведь Flexpod это не готовый продукт, а blueprint. Если у меня уже есть элементы, которые поддерживаются архитектурой Flexpod, то я могу «сам» (скорее сертифицированный партнер NetApp/Cisco) собрать всю инфраструктуру.
Задняя крышка скользкая, неудобно. В остальном очень доволен.
Про дедупликацию сейчас речь не идет. Это тема отдельная, там свои заморочки.
EMC Networker
А в общем случае, дисковая система выигрывает у ленты так же в силу дополнительного функционала:
— дедупликация
— репликация
— client direct LAN (клиентский сервер может напрямую отправлять данные дисковой системе, без участия медиа-сервера)
— почему не записать стандартные, повторяющиеся фразы в формат mp3 или gsm, вместо того чтобы обращаться каждый раз к гуглу (”Здравствуйте! После звукового сигнала произнесите имя абонента”)? Это реально в продакшине или для примера показано?
— какова задержка обработки в обоих случаях: googletts.agi и speech-recog.agi
Получается, что проще управлять всей этим через одно, пусть платное решение, чем несколько разрозненных утилит.
P.S. Если существует opensource решение отвечающее этим требованиям — тем лучше, правда я не знаю такое. Подскажите, возьму на заметку.
— интеграция его собств. датацентра и облака
— миграция в облако: методы, планировка
— как дать доступ партнерам к облаку по Интернет + ssl
— возможность виртуализации AIX
— можно ли иметь несколько зон в облаке
— патч-менеджмент опер. систем и ПО: какой процесс и периодичность
— может ли оператор разместить у себя в ДЦ особую аппаратуру клиента (riverbed, etc.)
— какие доп. средства может предоставить оператор (scheduler, cmdb, ...)
— а так же много запросов по поводу управления (все что относится к itilv3): роли, обязанности
В итоге такой чек-лист актуален, когда переноситься ИТ-инфраструктура в облако, а не просто два-три сервера.
Будет, по крайней мере это нам обещал Cisco и NetApp. Это и логично, ведь Flexpod это не готовый продукт, а blueprint. Если у меня уже есть элементы, которые поддерживаются архитектурой Flexpod, то я могу «сам» (скорее сертифицированный партнер NetApp/Cisco) собрать всю инфраструктуру.