Blog of Khlebalin Dmitriy

(Дорогу осилит идущий…)

Chromebook pixel с ChromeOS совсем не мое.

Сегодня ко мне в руки попал Chromebook pixel (первый или второй я не посмотрел, но с отличным железом на борту Core i7, 16gb, ssd, все дела) с  установленной ChromeOS. ChromeOS я вообще увидел первый раз, ранее никогда не доводилось столкнуться с ней.

Немного поюзав его, понял одну простую для себя вещь: Chromebook pixel с ChromeOS совсем не мое.

Все как-то не так и как-то не там чтоль, нет сложившегося прижившегося годами уклада. Для меня эргономика пользования им равна нулю-это бесконечное прокачивание ненависти.  Тот же XUBUNTU, установленный у меня на другом ноуте, показался мне мега удобной и привычной ОС. Но после часа в попытках настроить под себя ChromeOS, я понял, как хороша и удобна всеми ругаемая винда, именно для пользователя и для меня в том числе.

Хотя тот-же  XUBUNTU можно установить и сюда: https://ubuntuforums.org/showthread.php?t=2220912

и если бы это был мой ноут, я бы безусловно так и сделал. А люди поэтому и обратились с просьбой, сделать что-нибудь так, чтобы этим было удобно пользоваться.

Поэтому прежде чем приобрести такой вариант, 10 раз подумайте, будет ли удобен он для Вас?

Всем хорошей работы!!!

 

Реклама

30.03.2018 Posted by | linux and unix | Комментарии к записи Chromebook pixel с ChromeOS совсем не мое. отключены

Новый DC на Windows 2016. Устанавливаем контроллер.

В прошлом посте, рассказал, как объединить порты для отказоустойчивости. Поочередно пробуем выдернуть каждый провод из свича, пинг не пропадает, значит все работает, как положено.

Далее пришло время поднять сервер до контроллера домена.

Если внутри сети есть акцесс листы на фаерволах (у нас их нет, но тем не менее), обращаем внимание на доступность следующих портов:

TCP и UDP порт 88 -Kerberos авторизация;
TCP и UDP порт 135 -взаимодействие контроллер-контроллер и контроллер-клиент;
TCP порт 139 и UDP порт 138 -File Replication Service между контроллерами домена;
TCP и UDP порт 389 для -LDAP запросы от клиент-сервер;
TCP и UDP порт 445 -File Replication Service;
TCP и UDP порт 464 -смена пароля Kerberos;
TCP порт 3268 и TCP порт 3269 -доступ к Global Catalog от клиент-контроллер домена;
TCP и UDP порт 53 -DNS запросы;

Далее имеет смысл еще разок, для тех кто забыл, ознакомиться вот с этим:

https://docs.microsoft.com/ru-ru/windows-server/identity/ad-ds/deploy/install-a-replica-windows-server-2012-domain-controller-in-an-existing-domain—level-200-

Поднимаем контроллер, по старой памяти я попробовал cmd-dcpromo. Но как оказалось, более такой команды нет, предлагается установить контроллер через Диспетчер серверов.

Открываем Управление-Добавить роли и компоненты

При установке контроллера может возникнуть ошибка установки, и у нас она возникла. Контроллер не поднялся с первого раза, отругавшись. В нашем случае помогла перезагрузка сервера, при перезагрузке накатилось еще пара обновлений. Но если перезагрузка не помогает, то может помочь еще вот такой вариант.

http://www.it-article.ru/windows/ne-udaetsya-povysit-rol-servera-do-kontrollera-domena-windows-server-2012

Со второго раза все успешно отработало, и третий контроллер успешно поднялся.

Ставим утилиту Active Directory Replication Status Tool

https://www.microsoft.com/en-us/download/details.aspx?id=30005

Проверяем, что репликация успешна.

Видим, что все работает в штатном режиме.

Далее имеет смысл приступить к переносу ролей, но это уже тема последующих повествований.

Всем хорошей работы!!!

29.03.2018 Posted by | ms windows 2016 | Комментарии к записи Новый DC на Windows 2016. Устанавливаем контроллер. отключены

Новый DC на Windows 2016. Объединяем сетевые адаптеры.

Предыстория…

В текущем исполнении у нас два контроллера домена:

— Primary AD железный (достаточно старый еле ползущий сервак HP, от которого мы планировали избавиться)

— Secondary AD виртуальный (уже все как положено, быстрый на Windows 2012).

Некоторое время назад, столкнулись с интересной проблемой:

Судя по логам, в пятницу вечером, «воткнул» основной контроллер. Не просто «воткнул» полностью, а «воткнул» как-то странно (продолжал пинговаться, но войти удаленно на него уже было нельзя и свою роль он уже также не выполнял). Вроде воткнул и воткнул, есть же второй контроллер. Но в воскресенье днем пропала доменная авторизация на всех устройствах, хотя второй контроллер был вроде как доступен. А далее интересный момент. Как только пропала авторизация, второй контроллер перестал удаленно пускать в систему по RDP, решили посмотреть, что происходит с ним через Vcenter, но тут тоже нас ждал «отлуп», авторизация также не проходила, а самое интересное никак невозможно было попасть на виртуальный второй контроллер. Получился некий замкнутый круг: PDC в «дауне», а что случилось с SDC, тоже невозможно посмотреть и понять, что с ним происходит.

Соответственно все виртуальные сервера продолжали работать, но уже не так хорошо, как были должны. Впервые за свою практику, столкнулся с похожей ситуацией.

Далее пошли по следующему пути:

— Ребутнули железный PDC, он благополучно перезагрузился и поднялся, стал работать по-прежнему, как надо, но репликации со вторым контроллером так и не появилось. Это нам говорило о том, что второй контроллер хоть и пингуется, но тоже в анабиозе.

— Далее авторизуемся локально на Vcenter понимаем на каком хосте крутится SDC, далее уже принудительно ребутаем SDC, он благополучно поднимается, поднимается репликация с PDC, но авторизация на всех остальных (файл-серверах, терминальных серверах и прочих серверах…), так и не работает.

— Пришлось принудительно перезагрузить все виртуальные сервера, чтоб полноценно восстановить работу и вернуть их в строй.

Неприятный момент.

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

Наконец наш новый сервер DELL уже в стойке, Windows Server 2016 уже «залит», пришло время поэтапно приступить к поднятию третьего контроллера и дальнейшему PDC переносу на него.

Но сначала для отказоустойчивости имеет смысл объединить сетевые порты:

Соответственно из разных сетевых портов  сервера включаем шнурки в разные коммутаторы, на этих портах коммутаторов, включаем LACP.

На втором аналогично.

Далее, переходим непосредственно к серверу.

По умолчанию режим NIC Teaming в Windows server 2016 (в 2012 аналогично) отключен. Для его активации открываем Server Manager и видим, что это действительно так.

В Задачах (Tasks) выбираем пункт Создать группу (New Team).

 

Далее именуем группу, выбираем отмечаем адаптеры и настраиваем дополнительные свойства группы.

Имеет смысл сказать несколько слов о дополнительных параметрах настройки NIC Teaming в Windows server 2016:

Режим поддержки групп (Teaming mode) определяет режим взаимодействия группы с сетевым оборудованием:

1. Не зависит от коммутатора (Switch Independent) — группа работает независимо от коммутатора, никакой дополнительной настройки сетевого оборудования не требуется. Этот режим позволяет подключать адаптеры одной тиминговой группы к разным свичам для защиты от сбоя одного из них. настройка по умолчанию;
2. Статическая поддержка групп (Static Teaming) —  режим с зависимостью от сетевого оборудования. Все адаптеры группы должны быть подключены к одному коммутатору. Порты коммутатора, к которым подключены адаптеры группы, настраиваются на использование статической агрегации каналов;
3. LACP — режим с зависимостью от сетевого оборудования. Коммутатор настраивается на использование динамической агрегации каналов с использованием протокола Link Aggregation Control Protocol (LACP).

Режим балансировки нагрузки (Load Balancing mode) определяет, каким образом распределять сетевой трафик между адаптерами группы:

1. Хэш адреса (Address Hash) — при передаче сетевого трафика на основании MAC или IP-адресов отправителя и получателя вычисляется хеш (некое число). Это число привязывается к определенному физическому адаптеру и в дальнейшем весь трафик от этого отправителя будет идти через этот адаптер;
2. Порт Hyper-V (Hyper-V Port) — в этом режиме осуществляется привязка адаптера teaming группы к определенному порту виртуального свича в Hyper-V. Этот режим используется в том случае, если на сервере активирована роль Hyper-V.

Резервный адаптер (Standby adapter) позволяет назначить один из адаптеров группы в качестве резервного.  В нормальном состоянии резервный адаптер не используется для передачи трафика, но при выходе любого адаптера группы из строя сразу занимает его место и трафик продолжает передаваться без перерывов. Но даже без резервирования выход из строя одного адаптера в NIC Teaming не приведет к прерыванию сетевого соединения, потому что, нагрузка будет автоматически распределена по оставшимся адаптерам.

Тоже самое можно сделать и через PowerShell:

New-NetLbfoTeam -Name LACP -TeamMembers ″Ethernet″,″Ethernet 2″ ` -TeamingMode SwitchIndependent -LoadBalansingAlgorithm TransportPorts

Далее в окне «Сетевые подключения» появиться еще один сетевой адаптер, который как раз и является виртуальным адаптером созданной группы.

При необходимости все это можно удалить:

Или через PowerShell: Remove-NetLbfoTeam -Name LACP

Порты объединены, можно будет приступить к следующим этапам, но это уже тема последующих постов…

Всем хорошей работы!!!

 

 

28.03.2018 Posted by | ms windows 2016 | 1 комментарий