четверг, 22 сентября 2016 г.

Unmounting a LUN using the vSphere Client


Unmounting a LUN using the vSphere Client

To detach a storage device using the vSphere Client, see the Detach Storage Devices section in the vSphere 5.0 Storage Guide.

Caution: You must successfully unmount the datastore using the documented method prior to completing the steps described below. For more information, see the Unmount VMFS or NFS Datastores section in the vSphere 5.0 Storage Guide.

To unmount a LUN from an ESXi 5.0 host using the vSphere Client:
  1. If the LUN is an RDM, skip to step 2. Otherwise, in the Configuration tab of the ESXi host, click Storage. Right-click the datastore being removed and click Unmount.

    A Confirm Datastore Unmount window appears. When the prerequisite criteria have been passed, click OK.

    Note: To unmount a datastore from multiple hosts in the vSphere Client, click Hosts and Clusters > Datastores and Datastore Clusters view (Ctrl+Shift+D). Perform the unmount task and select the appropriate hosts that should no longer access the datastore to be unmounted.

  2. Click the Devices view (under Configuration > Storage):



  3. Right-click the NAA ID of the LUN (as noted above) and click Detach. A Confirm Device Unmount window is displayed. When the prerequisite criteria are passed, click OK. Under the Operational State of the Device, the LUN is listed as Unmounted.

    Note: The Detach function must be performed on a per-host basis and does not propagate to other hosts in vCenter Server. If a LUN is presented to an initiator group or storage group on the SAN, the Detach function must be performed on every host in that initiator group before unmapping the LUN from the group on the SAN. Failing to follow this step results in an all-paths-down (APD) state for those hosts in the storage group on which Detach was not performed for the LUN being unmapped.

  4. Confirm if the LUN is successfully detached. The LUN can then be safely unpresented from the SAN. For more information, contact your storage array vendor.
  5. Perform a rescan on all ESXi hosts which had visibility to the LUN. The device is automatically removed from the Storage Adapters.
When the device is detached, it stays in an unmounted state even if the device is re-presented (that is, the detached state is persistent). To bring the device back online, the device must be attached.

If you want the device to permanently decommission from an ESXi host, manually remove the NAA entries from the host configuration:
  1. To list the permanently detached devices, run this command:

    # esxcli storage core device detached list

    You see output similar to:

    Device UID State
    ------------------------------------ -----
    naa.50060160c46036df50060160c46036df off
    naa.6006016094602800c8e3e1c5d3c8e011 off


  2. To permanently remove the device configuration information from the system, run this command:

    # esxcli storage core device detached remove -d NAA_ID

    For example:

    # esxcli storage core device detached remove -d naa.50060160c46036df50060160c46036df

среда, 21 сентября 2016 г.

Soft RAID, замена HDD

После выключения не грузилась OS, не собирался RAID1 раздел boot.
Попробовал

mdadm --assemble --force /dev/md126

ни чего не изменилось, тогда 

mdadm --run /dev/md126 

раид поднялся, одного диска не хватает . Не понял почему при наличии исправного sda (sdc вышел из строя)  /boot не поднялся, а при этом / (root на sda2) поднялся нормально.


И собственно по замене диска
 

sfdisk -d /dev/sda | sfdisk /dev/sdc
mdadm --manage /dev/md126 --add /dev/sdc1
mdadm --manage /dev/md127 --add /dev/sdc2
grub2-install /dev/sdc



пятница, 15 июля 2016 г.

1C

Проблемы с базой, решения.
отсюда


Всё о сокращении Transaction Log для MS SQL 2008/2012


Рассмотрены пожалуй все варианты проблем из за которых журнал транзакций может не сокращаться и все варианты решений. От простейших, до "не рекомендуемых".
Для MS SQL 2008/2012 рекомендации ИТС уже устарели, кроме того и раньше они не всегда помогали. В статье попытался собрать наиболее полный комплект информации по данному вопросу.
В своё время в одном месте всего этого не нашел, поэтому думаю будет полезно.


Популярная статья ИТС http://its.1c.ru/db/metod81#content:2373:1 устарела - теперь уменьшение размера журнала транзакций стало не самой простой операцией.

Собственно там рекомендуется следующий скрипт:


BACKUP LOG Имя_Базы_Данных WITH TRUNCATE_ONLY
go
DBCC SHRINKFILE(Имя_Файла_Журнала_Транзакций) 
go

Если выполнить его в MS SQL 2008/2012 получите ошибку:

'truncate_only' is not a recognized BACKUP option
Подробно:
http://social.msdn.microsoft.com/Forums/sqlserver/en-US/9997e75e-f126-4901-9379-de540a708ec9/backup-log-with-truncateonly


Что теперь делать?
Решения, собственно два:

1)
USE [Database] ALTER DATABASE [Database] SET RECOVERY SIMPLE
go
 

DBCC SHRINKFILE ([Database]_log, 1); 
ALTER DATABASE [Database] SET RECOVERY FULL
go


2)
USE [Database]
BACKUP LOG [Database]  TO DISK='NUL:'
go
 
DBCC SHRINKFILE ([Database]_log, 1)
go


Если "Урезанием лога" не злоупотреблять (т.е. сокрашать лог вместе с полной копией) то по большому счету не принципиально каким методом пользоваться.
Второй вроде как правильнее, зато первый "надежнее".

На этом казалось бы можно и остановиться, но зачем тогда отдельную статью писать. Нет, конечно это ещё не всё. Обычно вопросы про урезание лога возникают когда это сделать не получается.
Притом способы, описанные выше, как правило, описаны не раз, все их освоили и проблем не вызывают.

Итак, если все действия, описанные выше не помогли - лог файл по-прежнему занимает N гигабайт. Переходим к плану B:

select log_reuse_wait_desc from sys.databases
В результате можете получить 3 варианта:

а. Пусто - Обычно это означает что у БД лог можно хоть сейчас полностью сократить, могу предложить только попробовать ещё раз Shrink, а если не поможет - переходить к плану C
b. Log_Backup - Нормальный варинат. В данном случае говорит о том, что Backup Log не выполнено, или выполнено некорректно
b. Replication - значит что ваш лог не обрезается из за репликации - скорее всего ошибки.
с. Active transactions -  Самая частая ситуация - в базе есть подвисшие транзакции, с ними нужно разобраться.

Replication  - Репликация для систем на платформе 1С, пожалуй, бессмысленное дело. Потому как Read only баз MS SQL не бывает, средства создания распределенных систем в 1С есть собственне (да, я про РИБ). Для обеспечения отказоустойчивости гораздо лучше подходят кластерные технологии. Собственно рекоммендация простая:

sp_removedbreplication '[Database]'Собственно после этого бэкап и Shrink помогут. Если же вопреки здравому смыслу вы всё-таки хотите сохранить репликацию БД то конечно выполнять эту команду нельзя, а нужно разбираться с ошибками репликации. Но это уже тема отдельной статьи.

Active transactions - наиболее популярная история. В базе есть транзакции, которые не завершены, и чего то ожидают. Чащи всего такие транзакции получаются при потере сетевого соединения или "вылете" клиента 1С в момент записи в БД. В этом случае нужно собственно узнать какая транзакция "повисла":

DBCC OPENTRAN

После выполнения этой команды вы получите примерно следующий результат:

Transaction information for database 'master'.
Oldest active transaction:
SPID (server process ID) : 52
UID (user ID) : -1
Name          : user_transaction
LSN           : (518:1576:1)
Start time    : May 5 2014 3:30:07:197PM
SID           : 0x010500000000000515000000a065cf7e784b9b5fe77c87709e611500
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Из этого обилия информации ключевым является Start Time и SPID. Если транзакция в базе 1С выполняется боле нескольких секунд это уже означает что что-то не так. А если start Time будет минут 10 или более от текущего времени - такие транзакции (сеансы) нужно завершать. Но предварительно я бы рекоммендовал узнать что эта транзакция делала.Для завершения процесса можно ввести команду

KILL [Process ID]

Где Process ID - это тот самый SPID полученный на предыдущем шаге. При этом незавершенные транзакции откатятся средствами MS SQL Server. Возможно при "убийстве" процесса будут завершены и несколько сеансов 1С, но  вряд ли много. Сервер 1С поддерживает собственный пул соединений с MS SQL, соответственно соединения из этого пула используются только тогда, когда серверу что-то нужно от СУБД. При этом если соединение занято (а оно как видим занято) вряд ли оно будет использоваться для других процессов.

Но предварительно (!) если хотите всё-таки разобраться в проблеме рекомендую выполнить скрипт вроде:

DECLARE @sqltext VARBINARY(128)
SELECT @sqltext = sql_handle
FROM sys.sysprocesses
WHERE spid = [Process ID]
SELECT TEXT
FROM sys.dm_exec_sql_text(@sqltext)
GO
В результате вы получите текст команды SQL Server, на которой, собственно, всё и "зависло". Из неё вам нужна будет таблица в которую производилась запись, далее используя функцию "ПолучитьСтруктуруХраненияБазыДанных()" вы определите таблицу в терминах объектов метаданных в которую производилась запись и смотрите код. Как правило такие неприятные последствия происходят:

1) Ошибки в сетевых подключениях (для толстого клиента в т.ч. в сетевых подключениях клиентов, для тонкого - только в проблемах сети между сервером 1С и MS SQL).
2) Каких то неправильных действиях (отправка почты, запись в файл, запуск внешних обработок, чтения из файла) производимых в транзакциях (при записи, при проведении)

Собственно от них надо избавляться.


Если ничего не помогло (или план B)

ВНИМАНИЕ! Перед выполнением процедур, описанных ниже, сделать полную резервную копию файлов БД MS SQL нужно обязательно!!!!

Есть ещё один - более радикальный способ решения вопроса роста журнала транзакций MS SQL. Но я лично его бы не рекомендовал к использованию. Тем не менее, специалисты Microsoft тоже могут ошибаться,
и SQL Server может содержать ошибки, о которых мы регулярно читаем в BugFix, или же наблюдаем сами, поэтому приведу и этот способ.

Суть его заключается в том что журнал транзакций просто удаляется и создается новый. При этом вы конечно теряете информацию из него и БД можно будет восстановить только из полной копии (которую вы конечно перед этим сделали).

Конечно при этом, особенно если в базе были всё-таки не зафиксированные может быть нарушена логическая целостность, но для этого запускается CheckDB которая в общем и целом приводит базу в порядок. Для аналогии это то же самое что в 1С проврять ссылочную целостность с опцией "Удалять если не найден". Если транзакция полностью не зафиксирована, но от неё остались частично данные, что противоречит принципу атомарности транзакций - эти данные будут удалены.

Итак приступим:

1) Detach БД из списка

2) Фал *.ldf удаляем (вы же его сохранили уж, да?)

3) Файл *.mdf переименовываем (в любое имя какое нравится)

4) В MS SQL создаём новую (!!!) БД с тем же именем, с каким была "больная" БД

5) Останавливаем MS SQL Server

6) Новый *.mdf файл удаляем, а старый переименовываем под "старое имя", подменяя тем самым файл новой БД

7) Запускаем MS SQL Server. При этом будет "битая БД", далее мы её исправляем

8) ALTER DATABASE [Database] SET EMERGENCY 

9) exec sp_dboption [Database], 'single user', 'TRUE'Монопольный режим работы с БД

10) DBCC CHECKDB ([Database], REPAIRALLOWDATA_LOSS)Ключевая операция - "возвращает БД к жизни". Может выполняться достаточно долго - до получаса на больших БД. Ни в коем случае не прерывайте эту операцию. Результат, где будут собраны исправленные ошибки
на всякий случай сохраните

11) exec sp_dboption [Database], 'single user', 'FALSE'Сбрасываем монопольный режим

12) ALTER DATABASE [Database] SET ONLINEДелаем базу доступной.

После чего получаем БД с чистым новеньким логом. На самом деле операция достаточно проста и в большинстве случае не несёт никаких критических последствий. Но всё-таки рекомендую прибегать к ней только в крайнем случае. Описана она не раз и в разных вариациях. Привожу свой вариант, который показался наиболее простым и понятным.

Внимание !
При выполнении ALTER DATABASE база SET EMERGENCY, к базе не должно быть соединений (подключения пользователей), если подвисло и на следующие команды выдает сообщение Msg 5061, Level 16, State 1, Line 1 ALTER DATABASE failed because a lock could not be placed on database 'name'. Try again later. Msg 5069, Level 16, State 1, Line 1 ALTER DATABASE statement failed. надо убить все коннекты к данной базе, можно через монитор .

SELECT
    DB_NAME(dbid) as 'DBName'
    , loginame as 'Login'
    , COUNT(dbid) as 'Connections'

FROM
    sys.sysprocesses
WHERE
    dbid > 0
GROUP BY
    dbid
    , loginame
--------------------
SELECT name , dbid FROM master.dbo.sysdatabases order by name

---------------------------------------------------------

select DATABASEPROPERTYEX('<your database>', 'UserAccess')

ALTER DATABASE база SET EMERGENCY  - ????

ALTER DATABASE база SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DBCC CHECKDB ('база');
DBCC CHECKALLOC ('база');
DBCC CHECKDB ('база',repair_allow_data_loss);  
ALTER DATABASE база SET MULTI_USER;
-----------------------------------------------------------
взято с

Если необходимо восстановить просто базу из полной копии, то достаточно выполнить следующий скрипт:


RESTORE DATABASE [Имя базы данных] FROM DISK = 'Z:\SQLServerBackups\back.bak' WITH REPLACE

В случае, если необходимо восстановить последовательно сначала полную копию, разностные копии и журналы транзакций, тогда необходимо написать следующий SQL скрипт.

RESTORE DATABASE TEST_DB –восстанавливаем полную копию
   FROM test_db_full
   WITH NORECOVERY;
GO
RESTORE DATABASE TEST_DB –восстанавливаем разностную копию
   FROM test_db_diff
   WITH FILE = 1,
   NORECOVERY;
GO
RESTORE LOG TEST_DB –восстанавливаем журнал транзакций №1
   FROM test_db_tran_1
   WITH FILE = 1,
   WITH NORECOVERY;
GO
RESTORE LOG TEST_DB –восстанавливаем журнал транзакций №2
   FROM test_db_tran_2
   WITH FILE = 1,
   WITH NORECOVERY;
GO
RESTORE DATABASE TEST_DB
   WITH RECOVERY;
GO

Для восстановления БД можно использовать так же и SSMS.

понедельник, 30 мая 2016 г.

DHCP. Статические клиенты

Далее пример конфига для клиента без фиксированного ip адреса

    host happylaptop {
      hardware ethernet 00:0a:39:22:da:39;
      option host-name "happylaptop";
      option domain-name "example.com";
      ddns-hostname "happylaptop";
      ddns-domain-name "example.com";
    }

Затем идет пример для группы хостов, или секции group в dhcpd.conf

    group {
      option domain-name "example.com";
      ddns-domainname "example.com";

      host happylaptop {
        hardware ethernet 00:0a:39:22:da:39;
        option host-name "happylaptop";
        ddns-hostname "happylaptop";
      }

      host dellstation  {
        hardware ethernet 00:b1:48:2a:ad:9c;
        option host-name "dellstation";
        ddns-hostname "dellstation";
      }
    }

Далее идет пример клиента со фиксированным ip адресом

    host jukebox {
      hardware ethernet 01:d0:06:b8:68:34;
      fixed-address 192.168.0.5;
      ddns-hostname "jukebox";
      ddns-domain-name "example.com";
      option host-name "jukebox";
      option domain-name "example.com";
    }
 
Взято 

вторник, 5 апреля 2016 г.

На компьютере, оборудованном устройством Gigabit Ethernet, не удается подключиться к контроллеру домена и применить групповую политику

Не удалось получить имя контроллера домена в этой сети. (Указанный домен не существует или к нему невозможно подключиться. ). Обработка групповой политики прекращена.

Сертификат, полученный от удаленного клиентского приложения, не прошел проверку. Код ошибки - 0x80092013. Не удалось выполнить запрос на подключение SSL.  В данных содержится клиентский сертификат.

Не удалось получить имя контроллера домена в этой сети - Windows XP
Не удалось получить имя контроллера домена в этой сети. (Указанный домен не существует или к нему невозможно подключиться. ). Обработка групповой политики прекращена.

А так же разные ошибки UserEnev о связи с домен контроллером, хотя ПК только вошёл в домен и ДК он видит.

Проблемы могут быть из-за сетевой карты Gigabit Ethernet.

Решение:

    Запустите редактор реестра.
    Найдите следующий раздел реестра:
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
    Добавьте следующую запись реестра в
    Parameters
    подраздел:
    Имя: DisableDHCPMediaSense
    Тип данных: REG_DWORD (логическое)
    Значение: 1

    Примечание. Эта запись управляет действиями проверки состояния сетевого подключения. По умолчанию события проверки состояния сетевого подключения запускают выполнение действия DHCP-клиентом. Например, при появлении подключения клиент пытается получить аренду. При отключении клиент может перевести интерфейс и маршруты в неактивное состояние. Если присвоить этому параметру значение 1, DHCP-клиенты и не DHCP-клиенты будут игнорировать события проверки состояния сетевого подключения.
    Перезагрузите компьютер.

(http://support.microsoft.com/kb/239924)


На компьютере, оборудованном устройством Gigabit Ethernet, не удается подключиться к контроллеру домена и применить групповую политику

http://support.microsoft.com/kb/326152
-------------------------------------------------------------------------
Тип события:    Ошибка
Источник события:    crypt32
Категория события:    Отсутствует
Код события:    8
Дата:        11.08.2015
Время:        7:25:06
Пользователь:        Н/Д
Компьютер:    N5673
Описание:
Ошибка получения автоматического обновления последовательного номера стороннего корневого списка из: <http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootseq.txt> с кодом ошибки: Сетевое подключение не существует.

вторник, 29 марта 2016 г.

ЭЦП


Если закрытые ключи находятся в реестре то через КриптоПро CSP - Сервис - Скопировать копируете на какой-либо носитель, либо экспортировать ветку реестра с закрытыми ключами
Для 64-разрядных ОС HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Crypto Pro\Settings\USERS\\Keys
Для 32-разрядных ОС HKEY_LOCAL_MACHINE\SOFTWARE\Crypto Pro\Settings\USERS\\Keys

сами сертификаты - через консоль: Пуск\выполнить: certmgr.msc
Перейти в Личное\Сертификаты:
Выделить все (нужные) сертификаты, правой кнопкой - Все задачи -> Экспорт ... Указать формат: в p7b Обратно из p7b - можно через Импорт
Программистам 1С передать номер отпечатка сертификата