По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В этой статье рассказываем как восстановить потерянный или забытый пароль root пользователя в утилите VMware vCenter Server в версиях 5.5 и 6.0.
Для поздних версий инструкцию по сбросу пароля смотрите здесь.
Решение
В vCenter Server Appliance 5.5 и 6.0 пароль локальной учетной записи по умолчанию истекает через 90 дней. В vCenter Server Appliance 5.5 Update 1 срок действия пароля истекает также через 90 дней. Однако вы можете войти в систему через командную строку и обновить пароль после истечения срока действия пароля.
Чтобы решить эту проблему необходимо:
Повторно активировать учетную запись путем перезагрузки устройства vCenter Server
Изменить параметр ядра в загрузчике GRUB, чтобы получить оболочку с правами root.
Примечание: если учетная запись root недоступна через командную строку, такую как secure shell и интерфейс управления виртуальными устройствами (VAMI) (vCenter Server Appliance 5.5 и 6.0 Update 1), то это означает, что учетная запись root не активyf из-за истечения срока действия пароля.
Инструкция по повторной активации учетной записи и изменению ядра
Перезагрузите устройство vCenter Server с помощью клиента vSphere.
Когда появится загрузчик GRUB, нажмите пробел, чтобы отключить автозагрузку.
Примечание: после включения питания виртуальным машинам требуется небольшое время, чтобы выйти из BIOS/EFI и запустить гостевую операционную систему. Вы можете настроить задержку загрузки или принудительно запустить виртуальную машину поверх экрана настройки BIOS или EFI после включения питания.
Введите p, чтобы получить доступ к параметрам загрузки устройства.
Введите пароль GRUB.
Примечание:
Если устройство vCenter Server используется без изменения пароля суперпользовавтеля в интерфейсе управления виртуальными устройствами (VAMI), то пароль GRUB по умолчанию - vmware.
Если root пароль устройства vCenter Server сброшен с помощью VAMI, пароль GRUB - это последний пароль, установленный в VAMI для учетной записи root.
Используйте клавиши со стрелками для выделения устройства VMware vCenter Server и нажмите e для редактирования команд загрузки.
Прокрутите страницу до второй строки, отображающей параметры загрузки ядра.
Введите e, чтобы изменить команду загрузки.
Добавьте init=/bin/bash к параметрам загрузки ядра.
Нажмите Enter. Меню GRUB появится снова.
Введите b, чтобы начать процесс загрузки. Система загрузит оболочку.
Сбросьте пароль суперпользователя, выполнив команду passwd root.
Перезагрузите устройство, выполнив команду reboot.Если вы не можете перезагрузить устройство, выполнив команду reboot, то выполните следующие команды:
mkfifo /dev/initctl
reboot -f
Примечание: если учетная запись с правами root заблокирована в течение длительного времени, это может быть связано с отсутствием места в журнале сообщений.
Сопутствующая информация
В vCenter Server Appliance вы можете установить свой собственный период истечения срока действия пароля и схему предупреждений по электронной почте на вкладке Admin интерфейса управления виртуальным устройством (VAMI).
Адреса электронной почты, настроенные на вкладке Admin В VAMI (https://IP_address:5480 или https://VAMI_host_name:5480) будут получать уведомления по электронной почте каждый день в течение семи дней до истечения срока действия пароля. Параметры электронной почты, такие как ретрансляционный SMTP-сервер, настраиваются через клиент vSphere в настройках почты vCenter Server.
Интернет-мошенничество является огромной проблемой в современном мире. Постоянное развитие интернет-технологий дает мошенникам много возможностей для действий. Однако самой большой угрозой для компании являются не вредоносные программы, а невнимательность сотрудников, поведение которых может стать головной болью для многих специалистов по информационной безопасности.
Несомненно, люди являются самым слабым звеном в корпоративной сети. Если быть точным - его пользователи. Вы можете защитить себя от внешних угроз, собрав и установив лучшие средства защиты, но ничто не может защитить вашу организацию от безрассудства сотрудников. Например, сколько раз сотрудник загружал (сознательно или нет) вредоносное программное обеспечение и "случайно" устанавливал его на компьютер компании с помощью USB-накопителя? Он получил электронное письмо с подозрительным вложением и проигнорировал предупреждения антивируса, потому что он был чрезвычайно заинтересован в том, что он "такое интересное" получил в своем почтовом ящике. Он открыл и проверил, а сетевым администраторам пришлось потрудиться, чтобы понять, откуда взялась атака. Последние также часто, слишком доверяя брандмауэру на сервере, обходят необходимость устанавливать брандмауэр на компьютерах пользователей. Причина - стоимость, эффект - обычно все нормально, пока пользователь не заберет оборудование компании из офиса, где он подключится к незащищенной сети.
Брандмауэр Windows не является достаточной защитой. Поэтому стоит снабдить сотрудников минимальными знаниями, позволяющими им обходить хотя бы некоторые из атак или, если они происходят, распознавать их и минимизировать их последствия. Ниже приводится обсуждение наиболее распространенных видов онлайн-мошенничества.
Фишинг
Фишинг - вид мошенничества, направленный на вымогательство данных, обычно данных на электронную почту или банковский счет (логин, пароль), номера кредитных карт. Реализуется через фальшивые электронные письма с перенаправлением на фальшивый, но очень похожий на подлинный сайт электронного банка. Опасная операция в основном для пользователя из-за возможности фишинга номеров кредитных карт и ПИН-кода. Это может быть проблемой для компании, если пользователь использует бизнес-карты оплаты или имеет доступ к корпоративному аккаунту. Ответ на такое сообщение или нажатие на ссылку подтверждает правильность вашего адреса электронной почты (фишер рассылает спам, редко знает прямой адрес электронной почты), что подвергает его дальнейшим атакам в будущем;
Фарминг
Фарминг - более сложный и поэтому зачастую более опасный вид фишинга. Преступник совершает отравляющую DNS-атаку, которая перенаправляет пользователя на фальшивый веб-сайт, несмотря на то, что его использует действующая ссылка браузера. Другой способ атаки - заражение компьютера жертвы трояном, который позволяет вам изменять файлы вашего компьютера таким образом, чтобы они перенаправляли пользователя на фальшивый веб-сайт, даже если он ввел правильный адрес. В данном случае следует обратить внимание на элементы безопасности сайта, такие как SSL-сертификат или протокол безопасного соединения https //;
Кража личных данных
Кража личных данных - действие, направленное на получение как можно большего количества персональных данных пользователя с целью их использования для финансового мошенничества. В основном это касается физических лиц. Данные компании широко доступны в информационных системах. Однако кража личных данных опасна для сотрудников компании, которые несут последствия своей невнимательности, а возможные последствия могут быть обременительными для компании. И наоборот - если компания хранит какие-либо данные о разных людях, она должна гарантировать, что такая информация не будет украдена и использована в преступных целях. Аналогичным образом, сотрудники, имеющие доступ к базе данных, должны быть осведомлены о последствиях их "утечки" информации. К сожалению, сообщения средств массовой информации об утечках данных от компаний и учреждений появляются довольно часто, что указывает на то, что компания, хранящая данные, или ее сотрудники игнорировали политику и процедуры безопасности, применимые в каждой компании. Профилактика заключается в информировании сотрудников и ограничительном соблюдении процедур компании;
Scam
Scam 419 - также известный как нигерийский Scam состоит из рассылки спам-сообщений в виде сообщений о гигантских выигрышах, огромных активах - наследовании от родственников. Лицо, отправляющее электронные письма, обычно представляется как юрист или нотариус. Этот обман настолько мелок в своей простоте, что вряд ли кто-то "клюнет" на него, а мошенники быстро становятся мишенями и обезвреживаются. Проблема может быть, когда пользователь отвечает на такое электронное письмо или подтверждает получение. Затем он добавляется в список учетных записей, на которые имеет смысл рассылать спам, и его неприятности только начинаются;
"Поддельный интернет-магазин"
"Поддельный интернет-магазин" - мошенничество со стороны компаний, предлагающих товары по ценам, значительно ниже рыночных, или предлагающих покупку товаров данной компании в больших количествах без согласования цен. Поддельный магазин принимает платежи в основном кредитными картами. Цель проста - фишинг номеров кредитных карт. Проблема для компании может быть довольно значительной, если это карточка сотрудника работника. Это мошенничество, легко узнаваемое, каждая компания может быть проверена в регистрационных системах, в том числе и иностранных.
Сообщения с опасным вложением, которые могут содержать вредоносное ПО, которое ищет и отправляет данные с компьютера мошеннику. Проблема для частного пользователя, довольно безвредная для компании, поскольку в большинстве случаев на компьютерах компаний постоянно устанавливаются антивирусные программы. Если пользователь не игнорирует предупреждения системы безопасности, проблем быть не должно. Если он это сделает, сообщение о проблеме скоро будет отправлено сетевым администраторам, поскольку проблема может быть серьезной;
Комбинированные атаки
Комбинированные атаки - состоят в том, чтобы убедить пользователя принять участие в соревнованиях, онлайн-играх и так далее. Чтобы узнать результаты конкурса, нужно отправить SMS, причем очень дорогое. Отправляя SMS-сообщение, пользователь принимает правила, доступные на сайте (хорошо скрытые, чтобы он не нашел его слишком быстро), поэтому действие является законным. И тот факт, что он не читал эти правила - его проблема или компании, в которой он работает, и чей бюджет истощает. Более того, вместо работы он занимается весельем. Однако, если такой нерадивый сотрудник заплатит за телефонный счет, это должно его немного вразумить, и в дальнейшем он будет более осмотрительным.
Есть еще много видов интернет-мошенничества. Они представляют собой разновидность вышеперечисленного, являются их комбинацией или расширены дополнительными элементами. Программное обеспечение, установленное на оборудовании компании, должно эффективно предотвращать хотя бы некоторые из них, но ничто не защищает вас от проблем лучше, чем ваши собственные меры предосторожности и предосторожности при использовании сети Интернет.
Правила безопасности
Плохая компьютерная безопасность лучше, чем вообще ничего.
На компьютере должно быть установлено антивирусное программное обеспечение, которое должно регулярно обновляться.
Если компьютеры используются во внешних сетях, стоит установить дополнительный брандмауэр и антишпионское программное обеспечение. Брандмауэр внутреннего сервера не поможет в этом случае.
Компьютеры должны регулярно проходить полное сканирование на вирусы.
Сотрудники должны строго соблюдать политики и процедуры безопасности компании.
Основой является здравый смысл, программное обеспечение не поможет, если пользователь намеренно игнорирует предупреждения.
В интернете можно найти множество статей с описанием шаблонов масштабирования баз данных (БД), но, в основном, это разрозненная информация с перечислением методик и практически без объяснений.
Ниже приведено подробное руководство по шаблонам масштабирования БД, пошаговым объяснением принципов их работы и примерами использования.
Практический пример
Предположим, вы создали стартап, который предлагает совместные поездки по дешевой цене. Вы выбрали город для поездок, а первая реклама привлекла не более 10 клиентов.
Вы храните информацию обо всех клиентах, поездках, местах, бронированиях и историях заказов в одной и той же БД и, скорее всего, на одной физической машине. У вас нет навороченного кеширования или конвейера обработки больших данных, ведь ваше приложение только появилось. На данный момент это – идеальный вариант: в базе мало клиентов, и система, вряд ли, бронирует по поездке каждые 5 минут.
Но время идет. В вашей системе регистрируется все больше людей, ведь это самый дешевый сервис на рынке. Да и реклама сделала свое дело. Вы получаете по 10 заказов в минуту. Постепенно это количество увеличивается до 20, а затем и 30 бронирований в минуту.
В этот момент вы замечаете, что система начинает тормозить: время отклика API сильно увеличилось, а некоторые транзакции блокируются или зависают и, в конечном итоге, не проходят. Время ответа приложения также увеличилось, что вызвало недовольство клиентов. Как же решить эту проблему?
Шаблон №1 – оптимизация запросов и реализация пула соединений
Первое решение, которое приходит на ум: кэш слишком часто использует нединамические данные (история бронирования, история платежей, профили пользователей и т.д.). Но прикладным уровнем кеширования вы не сможете решить проблему с временем отклика API, предоставляющим динамические данные (текущее местоположение водителя, ближайшая машина для конкретного клиента, текущая стоимость поездки после выхода на маршрут и т.д.).
Вы приходите к выводу, что база данных слишком нормализована, поэтому вы решаете ее немного «разбавить» и добавляете несколько избыточных столбцов (такие столбцы часто попадают в операторы WHERE или JOIN ON в запросах). Это сокращает количество запросов на соединение, разбивает большие запросы на несколько маленьких и добавляет их результаты на прикладной уровень.
Можно заняться и параллельной оптимизацией – настроить подключения к базам данных. Внешние и клиентские библиотеки БД доступны практически для всех языков программирования. Для кеширования подключений к БД можно воспользоваться библиотеками пула соединений. Либо вы можете настроить размер пула соединений в самой СУБД.
Создание сетевого подключения – вещь весьма затратная, поскольку требует двусторонней коммуникации между клиентом и сервером. Пулы соединений помогают оптимизировать количество подключений. Библиотеки пула соединений реализуют мультиплексирование подключений – несколько потоков приложения могут пользоваться одним и тем же подключением.
Вы замеряете время отклика API и замечаете снижение задержки на 20-50% (или даже больше). На данный момент это хорошая оптимизация.
Затем вы расширили бизнес на еще один город и получили больше клиентов. Постепенно вы доходите до 80-100 бронирований в минуту. Ваша система не в состоянии справиться с таким объемом. Вы вновь замечаете увеличение времени ожидания API, а слой базы данных не справляется с нагрузкой. Но в этот раз оптимизация запросов не дает вам существенного улучшения производительности. Вы проверяете метрики системы и видите, что дисковое пространство заполнено, ЦП занят в 80% времени, а ОЗУ переполняется слишком быстро.
Шаблон № 2 – вертикальное масштабирование или масштабирование вверх
Изучив все системные метрики, вы не находите другого решения, кроме как обновить аппаратное обеспечение системы. Вы увеличиваете размер оперативной памяти в 2 раза, а объем диска – раза в 3. Это называется вертикальным масштабированием. Вы сообщаете группе по обслуживанию инфраструктуры, команде devops или агентам сторонних центров обработки данных (ЦОД) о необходимости обновления вашей машины.
Но как настроить саму машину для вертикального масштабирования?
Вы выделяете машину большего объема. Один из подходов заключается в том, чтобы не переносить данные со старой машины вручную, а настроить новую машину в качестве копии, или реплики (replica), уже существующего устройства, или источника (primary), прописав временную конфигурацию первичной реплики (primary replica). После завершения репликации назначьте новую машину в качестве primary и отключите старую. Поскольку обрабатывать запросы планируется на этой новой машине, все чтение/запись также будет вестись на ней.
Отлично. Вы прокачали систему, и теперь все работает намного быстрее.
Ваш бизнес идет на ура, и вы решаете расшириться еще до 3 городов. Теперь вы ведете деятельность в 5 городах. Трафик увеличился втрое, вы получаете по 300 заказов в минуту. Проблема с производительностью вернулась: размер индекса сильно сказывается на памяти, базу данных необходимо постоянно поддерживать, а сканирование таблицы с индексом замедлилось до невозможности. Вы подсчитали стоимость дальнейшего масштабирования системы, но цена не внушает доверия. Так что же делать?
Шаблон №3 – разделение ответственности на команды и запросы (CQRS):
Вы понимаете, что та самая большая машина не в состоянии обработать все запросы на чтение/запись. Да и чаще всего компаниям нужны транзакционные возможности на запись (write), а не чтение (read). Вас даже устраивает небольшая несогласованность данных или замедление операций read. В принципе, раньше это тоже не казалось вам проблемой. Вы решаете, что неплохо было бы разделить операции чтения и записи на физической машине. Это позволит отдельным машинам выполнять больше операций чтения/записи.
Теперь вы берете целых 2 большие машины и настраиваете их репликами для текущего компьютера. Репликация базы данных решит вопрос с переносом данных с primary машины на реплики. Вы перенаправляете все запросы на чтение (буква Q в CQRS, что означает «запрос» - Query) в реплики – любая реплика может обслуживать любой запрос на чтение. А все запросы на запись остаются на первичной машине. Возможна небольшая задержка в репликации, но в вашем конкретном случае это не критично.
Вариант с настройкой primary-replica вполне подходит для большинства стартапов среднего масштаба, получающих по сотням тысяч запросов ежедневно… но при условии, что компании периодически архивируют старые данные.
Вы вновь расширились на 2 города, и замечаете, что primary-машина не справляется со всеми запросами на запись. Многие такие запросы приходят с опозданием. Более того, задержка между primary и replica начинает сказываться на клиентах и водителях. Например, поездка завершена, клиент успешно ее оплачивает, но водитель не видит платеж, поскольку активность клиента – это запрос на запись, который идет на машину primary, а активность водителя – это запрос на чтение, который приходит на одну из реплик. Вся система настолько замедлилась, что водитель не видит платежа как минимум секунд 30, и это вызывает недовольство как со стороны клиента, так и у самого водителя. Как же поступить сейчас?
Шаблон №4 – репликация с несколькими источниками
Конфигурация primary-replica помогла вам успешно масштабироваться, однако теперь для операций записи не хватает возможностей. Быть может, вы согласитесь слегка пожертвовать быстротой запросов на чтение. А почему бы не перенести запросы на запись тоже в реплики?
В модели с несколькими источниками (multi-primary) все машины работают как источник, и как реплика. Такая структура чем-то напоминает замкнутый круг из машин: A->B->C->D->A. «B» может реплицировать данные из «A», «C» – реплицирует данные из «В», «D» – дублирует данные из «C», а «A» делает тоже самое из «D». Вы можете выполнять операцию чтения и одновременно записывать данные в любой узел; вы можете транслировать запрос во все узлы, а значение вернет один из откликнувшихся узлов. Все узлы имеют одинаковую схему БД, один и тот же набор таблиц, индекс и т.д. Но нужно следить, чтобы в узлах одной таблицы не было конфликта по id , иначе при трансляции запросов несколько узлов вернут разные данные по одному и тому же id.
Вообще считается, что для ID лучше использовать UUID или GUID. Еще один недочет данной системы: из-за трансляции запросов и поиска корректного результата, запросы на чтение могут оказаться неэффективными. Это, своего рода, принцип распределения/сборки в действии.
И вот вы вновь масштабировали бизнес. В этот раз на 5 новых городов. Система не справляется. Теперь вам нужно обрабатывать по 50 запросов в секунду. Вам очень не хватает обработки большого количества параллельных запросов. Но как это сделать?
Шаблон №5 – декомпозиция
Вы знаете, что база данных location получает много трафика на чтение/запись. Вполне возможно, что соотношение записи к чтению составляет 7:3. Это создает большую нагрузку на существующие БД. В таблицах location содержится несколько первичных данных: долгота (longitude), широта (latitude), отметка времени (timestamp), ID водителя (driver id), ID поездки (trip id) и т.д.
Там практически нет информации о поездках или данных пользователя, его платежах и т.д. Возможно, стоит разделить таблицы location на отдельную схему? Как насчет того, чтобы распределить эту БД по отдельным машинам с корректно настроенной конфигурацией primary-replica или multi-primary?
Это называется декомпозицией данных по функциональности. В разных БД можно хранить данные, разделенные по функциональному признаку, а результат (при необходимости) агрегируется на серверном уровне. Такой способ позволит вам масштабировать нужный функционал с большим количеством запросов на чтение/запись. В то же время прикладной или серверный уровень приложения должен будет заняться объединением результатов, что приведет к значительному изменению кода.
Теперь представьте себе, что вы масштабировались до 20 городов в своей стране и планируете открыть филиалы в Австралии. Растущий спрос на ваше приложение требует все более быстрого времени ответа. Ни один из методов выше с этим не поможет. Вам нужно масштабировать систему так, чтобы при расширении в другие страны/регионы не приходилось слишком часто проектировать и менять архитектуру. Как же тогда поступить?
Шаблон №6 – горизонтальное масштабирование
Вы хорошо загуглили эту тему, почитали массу статей о том, как другие компании решали такую проблему, и поняли, что настал момент масштабироваться горизонтально. Вы выделили, скажем, 50 машин – все с одинаковой схемой БД и одинаковыми наборами таблиц. На каждой машине хранится лишь часть данных.
Поскольку во всех БД хранится один и тот же набор таблиц, вы можете спроектировать систему таким образом, чтобы реализовать привязку данных (то есть все связанные данные хранятся на одной машине). В каждой машине может быть своя реплика; реплики используются для восстановления после сбоя. Каждая такая база данных называется «шардом». На физической машине может быть один или несколько шардов – их количество зависит от нужной вам схемы проектирования. Вы должны придумать ключ шардирования, который бы всегда относился к одной и той же машине. Представьте себе много машин с кучей связанных данных в одном наборе таблиц; операции на чтение/запись запрашиваются для одной и той же строки или набора ресурсов на одной и той же машине с БД.
Реализовать шардинг довольно сложно. По крайней мере, так говорят инженеры. Но при обслуживании миллионов или даже миллиардов запросов, рано или поздно вам придется пойти на столь непростой шаг.
Настроив шардинг, вы уверены, что сможете масштабироваться во многие страны. Ваш бизнес разросся настолько, что инвесторы вынуждают вас расширяться на другие континенты. И тут опять возникают проблемы. Все то же время отклика API. Ваш сервис находится в США, и у пользователей из Вьетнама возникают трудности при бронировании. Но почему? И что же делать?
Шаблон №7 – умное сегментирование центров обработки данных
Ваш бизнес развивается в Америке, Южной Азии и нескольких странах Европы. Каждый день вы получаете миллионы заказов, а ваш сервер атакуют миллиарды запросов. Поздравляю! Это пиковый момент в вашей деятельности.
Запросы из приложения поступают с разных континентов и проходят через сотни или даже тысячи серверов в интернете, поэтому время отклика растет. Может, распределить трафик по центрам обработки данных? Вы могли бы настроить ЦОД в Сингапуре, и он бы обрабатывал все запросы из Южной Азии. Затем сделать еще один в Германии – он займется всеми запросами из европейских стран, и оставить ЦОД в Калифорнии для обработки американских запросов.
Кроме того, вам понадобится репликация между ЦОД – на случай, если потребуется восстановление после сбоя. Если центр обработки данных в Калифорнии выполняет репликацию сингапурского ЦОД, то в случае аварии в Калифорнии (стихийные бедствия, отсутствие электричества и т.д.), все запросы из США будут передаваться в Сингапур и наоборот.
Такой метод масштабирования подходит для: обслуживания миллионов клиентов из разных стран, сохранения всех данных и поддержания постоянной доступности системы.
Заключение
В статье приведены общие методы по масштабированию базы данных. Стоит сказать, что у большинства инженеров нет достаточных возможностей для реализации всех шаблонов. Но лучше знать о существовании таких схем, которые в будущем могут помочь вам с проектированием архитектуры и систем.