Category: Поддръжка

Домашен дейтацентър или лаборатория|HomeLab, Home Data center

Много devops, програмисти, системни и мрежови администратори изграждат свои домашни лаборатории, мини дейтацентрове, включително доста амбициозни и сериозно направени системи…

В тази статия разглеждам някои от съществените лимити, с които следва да се съобразяваме в амбициите и инвестициите си.

Тъй като е удобно и дори изглежда изгодно да натоварим домашната си лаборатория със сериозни задачи (например проекти за клиенти) – изхождайки от опита си за проектиране и изграждане на сериозна домашна лаборатория (от клас мини дейта център :), споделям лош опит, в желанието си да спестя на читателя настъпването на някоя и друга мотика по пътя. 😉

1. Не правете голяма инвестиция – в крайна сметка домашната лаборатория е за тестове и PoC (Proof of Concept), използването и за други цели рано или късно води до задънена улица и по някое време ще се наложи да отпишете инвестираното и направите нещата както трябва.
Все пак, по-долу (т. 7.) описвам добра (макар не изключителна) идея, която може да осмисли сериозното използване на домашната инфраструктура.

Така че – инвестирайте разумно и пестеливо, за да не загубите много (пари, време, нерви, недоволни клиенти и пропуснати възможности).

2. Причината да отпишете инвестицията е, че домашният дейтацентър не скалира добре – нито в посока повече оборудване, но винаги ще е зле в посока отказоустойчивост и надеждност на работата.

Винаги! Винаги!!

Дали съм достатъчно категоричен?

Винаги!!!

3. Имайте предвид, че много рядко електрическите инсталации в стандартните жилища са оразмерени добре, за да поддържат
7 x 24 x 365 дори малки товари от 1-2KW. Това не винаги се забелязва и никога не е проблем в началото, но е добре да се провери след няколко месеца работа дали предпазителите и изходните шини не греят. Следващите индикатори са черни конвективни следи над таблото, миризма на изгоряло и вой на пожарни сирени.

4. Проблемите с шума са добре известни и всеки чувал стартиращ или натоварен сървър има ясна звукова представа за тях. :). Ще добавя само, че шумът от вентилаторите на средномощен сървър, в някои сгради се чува и през нощта, включително И от съседите.
Разбира се, те не са чак такъв проблем, но помислете за отношенията си с партньора… 🙂  

5. Охлаждането – няма лесен и смислен начин да направите добро охлаждане, ако ще имате повече сървъри. Студеният въздух трябва да се движи отдолу нагоре и фронт/гръб спрямо сървърите (ако са за рак монтаж). Това, което можете да направите е да държите достатъчно ниска температурата в помещението, за да осигурите генерално температурния режим на оборудването, но тази схема консумира повече енергия и поради това е ценово неефективна.

Е, ако имате достатъчно средства може да заложите на рак със собствена климатизация, но това е инвестиция, която не си струва предвид описаното в т. 2.

6. Възможните компромиси –

– Ако просто имате нужда от домашен лаб – използвайте втора ръка мобилни работни станции – те дават доста мощност и са относително тихи (стига да не спите в едно и също помещение с тях). Предимствата им – не ви трябва UPS или KVM имате си вградени монитор, мишка и клавиатура.

– За ML (Machine Learning) – сглобете си машина с големи бавни вентилатори, не повече от един, но възможно най-мощен ускорител, например NVidia GeForce RTX 2080Ti. Пак ще шуми, но ако е в съседно помещение се търпи. Или не се търпи – зависи…

7. Направете си (или използвайте “as a service”) мониторинг – като минимум – температура на околната среда и на системите – трябва да знаете температурното им състояние и да получавате известия при надвишаване на допустимите рамки.

Разбира се мониторинга е необходим и за други цели – например: параметри на експлоатация, надеждност, сигурност, контрол на SLA.

Хубавото в тази схема е, че когато прехвърлите проектите си, където им е мястото – тогава домашната инфраструктура може да се използва за независим (или втори) мониторинг.

8. Ако правилно изберете оркестрацията на виртуализация/контейнеризация – ще можете лесно да мигрирате приложенията си към ваши ресурси в частни или публични клауд платформи. Така ще си запазите възможноста да правите бързи и евтини тестове и PoC в домашната среда, същевременно ще можете лесно да мигрирате продакшън системите на правилните платформи.

9. Спестете си проблеми със сигурността и надеждността и разделете правилно инфраструктурата за тестове и PoC от домашния си интернет, не ги смесвайте от самото начало най-добре – т.е. организирайте си файъруол (може и виртуализиран, но с много мисъл), умен суич/и.

Повтарям – от самото начало разделете едното от другото, никакъв компромис, временно решение и прочие.

ISPConfig

Кратко описание

ISPConfig е широко използван хостинг контролен панел (аналог на популярното комерсиално решение cPanel) с отворен код за Linux.

В тази статия разглеждам ISPConfig не толкова като контролен панел за хостинг провайдъри (работа, която той върши прекрасно), а като интегрирано и изключително удобно решение за управление интернет ресурсите на организация или бизнес. 

ISPConfig позволява на администраторите да управляват през единен уеб интерфейс уебсайтове, мейл сървъри, мейл интерфейси, бази данни MySQL и MariaDB, FTP сървъри, shell достъп, и DNS сървъри.

Тъй като е предназначен за хостинг провайдъри, ISPConfig поддържа йерархия на достъп в категории администратор, продавач, клиент и имейл потребител. Тази структура лесно се пренася и е изключително удобна и за управлението на ресурси в голяма организация с развита йерархия, но същевременно не пречи и не усложнява работата на малки организации. 

За разлика от популярен комерсиален продукт като cPanel, ISPConfig поддържа повече Linux дистрибуции  – CentOS, Debian, Fedora, OpenSUSE и Ubuntu

Поддържат се следните услуги и функции:
  • Управление на единичен или отказоустойчив клъстер от няколко сървъра през един контролен панел
  • Управление на уеб сървъри (Apache и Nginx)
  • Управление на мейл сървър (с виртуални пощенски кутии с антиспам и антивирусен филтър) Postfix и Dovecot
  • Управление на DNS сървър (BIND, Powerdns)
  • Управление на виртуални сървъри (OpenVZ)
  • Статистика за уебсайтове  (Webalizer и AWStats)
  • Софтуерен каталог с автоматична инсталация на уеб приложения (например WordPress)
Подходящ за:
  •  Управление на интернет ресурси на организация
Неподходящ за:
  • Изграждане на ентърпрайс клас уеб базирани информационни системи
За повече информация:
Защо ISPConfig:
  • Добре направен и много добре интегриран интерфейс към популярни софтуери за изграждане на интернет присъствие – 
    • DNS, Web, FTP, Mail, Antispam, Antivirus 
  • Достатъчно широка общност от разработчици и потребители
  • OpenSource решение
Недостатъци:
  • Няма вградена интеграция с LDAP или Active Directory (AD), за използване в корпоративна среда, но такава е възможно да се направи допълнително
Оценка на необходимите ресурси при внедряване:
  • Хардуер – в зависимост от нуждите и размера на организацията
  • Софтуер – инсталацията е добре документирана, има и скриптове за автоматизация – отнема около 1 час
Степен на завършеност на решението:
  • Завършенo решения
Съвети към IT мениджъра:
  • Поради добрата интеграция и единно управление на основни интернет ресурси си струва да се използва както при малки, така и за големи организации
  • Добре работи във виртуализирана среда, тоест не се налага използване на отделен сървър
  • Улеснява работата на IT отдела в организацията чрез интегрирано управление на интернет услуги през уеб интерфейс
  • Улеснява и ускорява провизирането (буквално няколко клика) на нови open source уеб приложения за нуждите на организацията, например: CRM, ERP, CMS (WordPress), Accounting, Billing, HR, Knowledge management, Support, Ticketing, Collaboration, Productivity, e-commerce, forums and bulletin boards).

IT инфраструктурата на стартираща компания

IT инфраструктурата на стартираща компания

Организация. Принципи. Решения. Управление на риск

1. TL;DR
  • Описани са съображения, принципи и правила при проектиране изграждане и експлоатация на IT инфраструктурата на стартираща компания;
  • Фактори за постигане максимална ефективност при оптимална цена;
  • Управление на IT рискове на стартиращата компания чрез избор на подходящи и изпитани решения;
  • Съвети за идентифициране на проблеми и пестене на време и нерви;
  • Препоръчват се изпитани решения базирани на отворен код.
2. Въведение

Настоящият документ е насочен основно към IT нуждите на технологична компания, но принципите и дизайн насоките са валидни за широк кръг компании, които по необходимост изграждат комплексна IT инфраструктура.

Водещи принципи –

  • Изграждане на необходимата IT инфраструктура, експлоатация гарантираща запазване на интегритет и пърформанс в работата на организацията
  • Оптимизиране на оперативните разходи при различни схеми на организация, включително с присъствени и отдалечени работни места.
  • Внедряване на изпитани решения, за които е натрупан достатъчно експлоатационен опит

Описват се основните положения и добри практики при проектиране и изграждане на виртуализирана, евентуално хиперконвергирана инфраструктура

Целта на документа е да предложи ефективно решение, което може да поддържа дейността на компании от всякакъв мащаб, като гарантира плавно развитие на инфраструктурата съобразно бизнеса на организацията.

Съдържание на: IT инфраструктурата на стартираща компания

The IT infrastructure of Startup company - CONTENTS

 

Можете да получите целия документ след регистрация.

Вашите лични данни ще бъдат обработени съгласно Условията на сайта.

Съгласно Условията на сайта, имате пълни права за използване на файла и информацията в него при съблюдаване на Creative Commons CC BY-SA лизенза. 

 


Съгласен


OpCenter – Design Guide

Ръководство за проектиране: Центрове за наблюдение и управление на IT инфраструктури

Настоящият документ описва основните положения и добри практики при проектиране и изграждане на центрове за наблюдение и управление, например:

  • Service Operation Center
  • Security Operation Center
  • Network Operation Center

Авторът визира основно центрове за наблюдение и управление в областта на информационните технологии, но голяма част от разглежданите принципи и направени препоръки са приложими и в други сектори.

Целта на документа е да осигури необходимото ниво на унификация, стандартизация и добри практики, за да се обезпечи безпроблемна и ефективна експлоатация на центровете за наблюдение и управление.

Авторът си поставя за цел да улесни организациите, които имат необходимост от изграждане на нов, респективно редизайн на съществуващ център за наблюдение и управление.

В съдържанието и само за пълнота на изложението, са маркирани използваните в един оперативен център софтуерни решения. Те не са развити в този документ.

Доколкото изграждането и поддръжката на такъв център е свързана с немалки инвестиции в оборудване и персонал, авторът препоръчва и запознаване с документ описващ:

Документът отразява авторовата експертиза в планирането, изграждането и експлоатацията на големи информационни системи в областта на интернет, телекомуникации и бизнес решения.

Съдържание на Ръководство за проектиране: Центрове за наблюдение и управление на IT инфраструктури

OpCenter - Design Guide - CONTENTS

 

Можете да получите целия документ след регистрация.

Вашите лични данни ще бъдат обработени съгласно Условията на сайта.

Съгласно Условията на сайта, имате пълни права за използване на файла и информацията в него при съблюдаване на Creative Commons CC BY-SA лизенза. 

 


Съгласен


DevOps Roadmap 2020

Кратко описание

Това, според Kamran Ahmed, е DevOps технологичният стек за началото на 2020г. 

 

Съвети към IT мениджъра:
  • Без претенции за всеобхватност и валидност за целия devops спектър, схемата дефинира примерен модел, който може да се следва от технологичните организации за изграждане и поддържане на модерна IT инфраструктура
  • Схемата е особено подходяща за фукционална визуализация на devops и sysadmin процесите в организацията и идентифицирането на необходимите ресурси и технологично ноу-хау
  • Препоръчително е CIO и IT мениджърите да имат предвид или да разработят подобна схема, която да подпомага процеса на търсене на нови и обучение служителите на организацията
  • Не че е невъзможно, но не е препоръчително да реализирате целия технологичен стек без по-тясна специализация и разпределение на роли в екипа

osTicket

Кратко описание на osTicket
  • Една от най-популярните системи за поддръжка на клиенти
  • Многостепенна йерархия от агенти за поддръжка
  • Добра система за справки и статистика, която може да се използва за контрол на SLA
Подходящ за:
  • Изграждане на хелп деск (help desk) / сървис деск (service desk) система за поддръжка на вътрешни и външни за организацията клиенти
Неподходящ за:
  • В рамките на заеманата ниша, osTicket е подходящ за изграждане на кол център и сървис деск от всякакъв мащаб. 
За повече информация:
Защо osTicket:
  • Добре направен и с много мисъл софтуер за организация на IT експлоатация 
  • Достатъчно широка общност от разработчици и потребители
  • Добро API за връзка с трети продукти – например мониторинг системи
  • Множество модули написани от трети страни, които разширяват възможностите му
  • Добре се вписва в корпоративна среда (LDAP/AD) и в политиката за сигурност на компанията
  • Функционален и модерен уеб интерфейс
Недостатъци:
  • Няма много материали на български език
Оценка на необходимите ресурси при внедряване:
  • Има относително добра документация за инсталация
  • Време за базово усвояване само на тази функционалност на osTicket: 2-4 часа.
  • Необходимост от оперативна поддръжка: средна (под 4-6 часа месечно, в зависимост от броя поддържани клиенти и възникващи казуси)
Степен на завършеност / Необходимост от развитие:

  • Завършено решение
  • За пълноценна работа е необходимa инсталация и конфигурация на допълнителни модули, което може да изисква промяна в кода на модулите, ако са разработвани за предишна версия на API
Съвети към IT мениджъра:
  • Струва си
  • Ако се търси support ticketing system решение с отворен код (open source) – osTicket върши смислена работа

GLPI

Кратко описание на GLPI

  • Предлага пълен комплект IT Service Management (ITSM) средства (ITIL V2)
  • Мощен модул за IT инвентар (IT inventory), включително с автоматично разпознаване (Fusion Inventory) и завеждане в инвентара на компютри, принтери, мрежово оборудване, софтуер, лицензи, консумативи, договори за поддръжка
  • Добър хелп/сървисдеск модул –
    • завеждане/отваряне на тикети през различни канали (мейл, уеб, може да се правят и други).
    • Разпределяне на задачи към вътрешни и външни изпълнители.
    • Knowledge base.
    • SLA контрол
    • Call center решение може да се направи с комерсиални модули за интегриране със софтуерна телефонна централа (Asterisk)
  • Проджект мениджмънт модул
  • Универсална система с широка приложимост в рамките на голяма организация
Подходящ за:
  • Базови ITSM процеси (ITIL V2)
  • Изграждане на система за поддържане на IT складово стопанство – инвентар (inventory) с ръчно и автоматично въвеждане на информацията
  • Изграждане на хелп деск (help desk) / сървис деск (service desk) система за поддръжка на вътрешни и външни за организацията клиенти
Неподходящ за:
  • Инвентар и складово стопанство извън IT областта
За повече информация:
Защо GLPI:
  • Добре направен и с много мисъл софтуер за организация на IT експлоатация 
  • Достатъчно широка общност от разработчици и потребители
  • Удобен за SLA контрол
  • Добро API за връзка с трети продукти – например мониторинг системи
  • Множество модули написани от трети страни, които разширяват възможностите на GLPI
  • Добре се вписва в корпоративна среда (LDAP/AD) и в политиката за сигурност на компанията
Недостатъци:
  • Web интерфейсът не е особено интуитивен и изглежда архаичен
  • Макар да има няколко андроид базирани безплатни мобилни клиента, нито един от тях не предоставя цялостно мобилно решение. Платените клиенти не си заслужават
  • Няма много материали на български език
  • Добра документация има на френски език. Документацията на английски език върши работа, но има липси
  • Тъй като API-то за връзка с допълнителни модули и външни системи е променяно неколкократно през годините – случват се несъвместимости
Оценка на необходимите ресурси при внедряване:
  • Има относително добра документация за инсталация
  • Изисква ръчна инсталация на базови компоненти (database, web server) и на множество php модули
  • Лек е за експлоатация
  • Време за базово усвояване: 4-6 часа
  • Необходимост от оперативна поддръжка: средна (под 4-6 часа месечно, в зависимост от типовите системи и устройства, които се инвентаризират)
  • При използване на модули от трети страни може да се направи добро call center решение за IT поддръжка 
Степен на завършеност / Необходимост от развитие:

  • Завършено решение
  • За пълноценна работа е необходимa инсталация и конфигурация на допълнителни модули, което може да изисква промяна в кода на модулите, ако са разработвани за предишна версия на API
Съвети към IT мениджъра:
  • Струва си
  • Ако се търси ITSM решение с отворен код (open source) – GLPI върши смислена работа