 |
Мастерская IT решений"….Нет смысла нанимать толковых людей, а затем указывать, что им делать . Мы нанимаем людей, чтобы они говорили , что делать нам … " Стив Джобс |
Бывают такие ситуации, когда по какой-то причине каталог виртуальных машин создался с ошибкой или при создании произошел разрыв связи с сервером управления. Как и полагается в результате мы имеем нежизнеспособный каталог, удалить который не представляется возможным.
Все рано или поздно, особенно после «любезного» общения с представителями софтверного гиганта Mictosoft задумываются про оптимизацию парка серверов / баз данных / клиентских рабочих мест. Естественно я тоже столкнулся с подобным вопросом. Пред историю рассказывать особо не буду, расскажу только один актуальный вопрос — консолидация серверов баз данных. В моей инфраструктуре было развернуто большое количество рабочих мест пользователей 1С. Первоначально базы естественно были на серверах MS SQL Server. С ростом численности персонала, стало очень затратно покупать все новые и новые «колы» и перешли к лицензированию на ядра. Проанализировав поддерживаемые б/д фирмой 1С выбор был остановлен на PostgreSQL.
Попробую кратко описать механизм миграции баз 1С с MS SQL на PostgresSQL, суть которого заключается в установке PostgressSQL сервера + экспорт-импорт базы из 1С.
Приступим:
Многие знают, что с выходом версии esx 5,0 появилась возможность использовать SSD накопитель не только как локальный сторадж, но и по другом назначениям. В первую очередь я имею ввиду HostCache. (Данный механизм полезен при активном использовании RAM в вашей инфраструктуре, особенно при overcommit памяти (например VDI решения).
С выходом версии 5.1 этот список расширился, и теперь стало доступны функции Swap to SSD, SSD Monitoring. Продолжая оптимизацию работы с SSD дисками, Vmware в версии 5,5 выпустила поддержку vFlash и которой я как раз и расскажу.
Суть заключается в использовании промежуточного звена SSD в качестве VM-aware caching и VM-transparent caching:
Т.е. технология vSphere Flash Read Cache работает с любыми типами дисковых массивов. Как следует из названия, это кеш только на чтение. Он не кеширует операции на запись.
Меня многие спрашивали относительно реализации самого vcenter server (физический или виртуальный) и я отвечал однозначно приводя многие доводы – виртуальный. Но как известно, у Vmware имеются 2 редакции vCenter Server (VCENTER Standard и vCenter Server Appliance — VCSA). В выборе редакции vCenter до выхода релиза 5.5 я бы однозначно рекомендовал использовать vcenter server ввиду ограничения на количество хост-серверов ESXi больше 5 и виртуальных машин больше 50. Согласитесь, для более-менее развитой современной инфраструктуры значения минимальные. Но все коренным образом изменилось с выходом версии 5.5. Так вот, Mware vCenter Server Appliance 5.5 позволяет использовать до 100 хостов ESXi и до 3000! виртуальных машин (при использовании встроенной БД), что полностью позволит обеспечить управляемость крупной виртуальной инфраструктуры и до 1000 хостов и 10000 ВМ при использовании внешней БД.
Получив такой подарок), многие задумываются о переходе с vmwarevcenterserverна vCenterServerAppliance. Но, как показывает практика, первый вопрос который возникает при миграции – перенос распределенных коммутаторов VMware vSphere Distributed Switch (vDS), которые несомненно более предпочтительные при реализации инфраструктуры визуализации. В статье опишу как перенос VDS, так и другие аспекты миграции на новый сервер.
А как быть если, мы имея 2х факторную авторизацию при помощи e-token или аналогичного ключа обеспечить вход с мобильных устройств. Сразу оговорюсь – под мобильными я буду использовать устройство на базе IOS Ipad. Почему – просто у него нет USB порта, следовательно, решение данной задачи сложнее и интереснее.
И так диспозиция:
— Будем считать, что ферма Citrix XenApp / XenDesktop серверов настроена. (об этом я много писал, и есть много англоязычных ресурсов)
— Настроена 2х факторная авторизация на Citrix NetScaler (тоже писал об этом)
— Естественно наличие настроенного центра сертификации и уже выданный сертификат пользователя.
— Установленный Citrix Receiver на ipad
Задача:
Обеспечение 2х факторной авторизации для организации гарантированного безопасного входа в корпоративную ИС c использованием IPad.
Если вы думаете, что после запуска в «промышленную эксплуатация» службы ServiceDesk все административные вопросы закончатся — то это глубокое заблуждение. Вопросы останутся, просто они видоизменятся и трансформируются в новом направлении.
1. Ротация сотрудников отдела Service Desk. Типовой пример на который нужно ориентироваться — первая линия поддержки. У операторов ServiceDesk зачастую очень быстро накапливаются необходимые навыки для перехода на другую должность или наоборот, т.е. быстрая ротация сотрудников при количестве операторов больше 4-5. Огромным плюсом правильно организованной ротации является то, что после операторской работы часто выходят перспективные кадры с пониманием проблем пользователей и базовым знанием всех ИТ-систем и предоставляемых ИТ-услуг организации.
2. Альтернативные способы работы. Ввиду того, что со временем Service Desk станет важным звеном при обслуживании пользователей, то перебой в ее работе стенает заметен заметен всей организации. Необходимо проанализировав ее работу иметь экспрессный план на случай оперативного восстановления доступа к нужной информации.
3. Контроль. Важная фигура данного этапа, это руководитель отдела Service Desk и вышестоящий руководитель подразделения ИТ. От них требуется не только постоянный мониторинг работы службы ServiceDesk, но и анализ деятельности службы с выдачей рекомендаций по его развитию.
4. Развитие. Кроме всего прочего, очень важно обратить внимание со стороны руководства подразделения ИТ, выраженное в постоянных докладах о работе службы ServiceDesk и рассмотрении предложений о дальнейшем развитии службы с учетом выявленных наработок и предложений.
Итогом работ по внедрению системы ServiceDesk станет существенные изменения в подходе к работе службы поддержки, закрываются многие типовые вопросы, оптимизируется работа. Но останется главный вопрос, который обычно адресуют топ менеджеры компании и руководители и начальнику отдела ИТ (руководителю ServiceDesk): Какова оценка эффективности внедрения системы ServiceDesk.
На мой взгляд, когда мы слышим такой вопрос — значит само внедрение ServiceDesk и его пост жизненный цикл прошели успешно. Это последний вопрос при внедрении ServieDesk, и на него я постараюсь ответить в следующих статьях.
Остается только один вопрос — а почему у Вас еще не внедрен SrviceDesk?
Создание службы Service Desk является в прежде всего организационной (административной) задачей. А это накладывает соответствующий отпечаток в виде необходимости подготовки соответствующей нормативной базы в виде регламентов, приказов, распоряжений.
Давайте рассмотрим типовое решение по созданию службы Service Desk, тут стоит кратко описать подход, согласно которому будет развиваться проект.
В соответствии с этим подходом задачи проектирования службы Service Desk можно разбить на следующие этапы:
1. «начало проекта» — это отправная точна, связанная с началом планирования работ, формирование проектной команды, решение организационных вопросов. Средняя продолжительность – 1–2 недели;
Мастерская IT решений © | 2013-2018 | При копировании или цитировании ссылка на сайт netolkoit.ru и автора обязательна!