По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В данной статье рассматриваются вопросы, которые следует задать системным администраторам, и меры предосторожности, которые они должны предпринять при устранении неполадок.
Как правило, устранение неполадок не рассматривается на каких-либо официальных занятиях, - это все то, что большинство из нас в конечном итоге усваивает на собственном горьком опыте. Как действовать, где искать, как определить первопричину возникших проблем - все это навыки, которые мы обычно развиваем с течением времени.
Жизненный цикл сеанса устранения неполадок обычно включает:
Обнаружение - обнаружение проблемы
Идентификация - понимание того, в чем проблема
Анализ - определение причины проблемы
Исправление - исправление того, что было не так
Профилактика - принятие мер для предотвращения повторения проблемы
Систематический подход к устранению неполадок может помочь быстрее выявить основную причину проблемы, которая нарушает работу сервера или приложения. Вот несколько шагов и вопросы, которые нужно задать себе:
1. Что только что изменилось?
Наиболее частая первая реакция на что-то, что перестает работать - это спросить: «Хорошо, а что изменилось?» Изучение последних изменений - это тоже действие, которое, скорее всего, окупится, если на самом деле какое-то существенное изменение было сделано только что. Ищите файлы, особенно файлы конфигурации, которые могли быть изменены, приложения или пакеты, которые были только что добавлены, службы, которые только что были запущены, и т. д. Не упускайте из виду тот факт, что многие системные проблемы возникают не сразу. Примеры того, что идет не так, не связано с недавним изменением, включают:
Медленно заканчивается место на диске
Можете столкнуться с ошибкой конфигурации, которая раньше просто не активировалась из-за несоблюдения определенных условий
2. Какие ошибки я наблюдаю?
Обратите особое внимание на любые ошибки, которые отображаются на системной консоли или в файлах журнала. Указывают ли эти ошибки на какую-то конкретную причину? Вы видели раньше подобные ошибки? Видите ли вы какие-либо проявление тех же ошибок в старых файлах журнала или в других системах? Что вам говорят поисковые запросы в Интернете? Независимо от того, с какой проблемой вы столкнулись, вы вряд ли будете первым системным администратором, столкнувшимся с ними.
3. Как себя ведет система или сервис?
Возможно, стоит обратить внимание на симптомы проблемы. Система или служба работают медленно или полностью непригодны для использования? Может быть, только некоторые пользователи не могут войти в систему. Может быть, не работают только некоторые функции. Выделение того, что работает, а что нет, может помочь вам сосредоточиться на том, что не так.
4. Чем эта система отличается от той, которая является рабочей?
Если вам повезло, что у вас есть дублирующие системы, и у вас есть шанс сравнить ту, которая не работает, с другой. Возможно, вы сможете определить ключевые различия, которые могут помочь выявить причину.
5. Каковы вероятные точки останова?
Подумайте, как работает приложение или сервис и как/где могут возникнуть проблемы. Полагается ли он на конфигурационный файл? Нужно ли ему общаться с другими серверами? Задействована ли база данных? Записывается ли он в определенные лог-файлы? Включает ли это несколько процессов? Можете ли вы легко определить, все ли необходимые процессы запущены? Если можете, систематически устраняйте потенциальные причины.
6. Какие инструменты для поиска и устранения неисправностей могут быть полезны?
Подумайте об имеющихся у вас инструментах для поиска системных проблем. Некоторые из них могут оказаться полезными:
top - для оценки производительности, включая проблемы с памятью, файлом подкачки и загрузкой
df - для проверки использования диска
find - для поиска файлов, которые были изменены за последний день
tail -f - для просмотра последних записей журнала и наблюдения за тем, появляются ли все еще ошибки
lsof - чтобы определить, какие файлы были открыты конкретным процессом
ping - быстрая проверка сети
ifconfig - проверка сетевых интерфейсов
traceroute - проверка подключений к удаленным системам
netstat - проверка сетевых подключений
nslookup - проверка разрешений хоста
route - проверка таблиц маршрутизации
arp - проверка IP-адреса на записи MAC-адреса в вашем кеше
7. Происходит что-нибудь неприятное?
Не исключайте возможность того, что кто-то вмешивался в вашу систему, хотя большинство хакеров предпочли бы делать свою работу так, чтобы вы ничего не заметили.
8. Что мне НЕ делать?
Не путайте симптомы и причины. Каждый раз, когда вы определяете проблему, спрашивайте себя, почему она существует. Будьте осторожны, чтобы не уничтожить «доказательства», пока вы лихорадочно работаете над тем, чтобы вернуть свою систему в оперативный режим. Скопируйте файлы журнала в другую систему, если вам нужно освободить дисковое пространство, чтобы вернуть систему в рабочее состояние. Затем вы можете изучить их позже, чтобы выяснить, что вызвало проблемы, над решением которых вы работаете.
Если вам нужно восстановить файл конфигурации, сначала сделайте копию файла (например, cp -p config config.save), чтобы вам было легче узнать, как и когда файл был изменен, и что вам нужно сделать, чтобы все заработало. Имейте ввиду, что для поиска решения возникшей проблемы вы, возможно, примените большое количество решений. И в последствии не сможете запомнить, какое из решений устранило проблему.
9. Что мне делать?
Запишите все свои действия. Если вы используете PuTTY для подключения (или какой-либо другой инструмент, позволяющий записывать взаимодействия с вашей системой), включите ведение журнала. Это поможет вам, когда вам нужно будет проанализировать, что произошло и как вы решили проблему. Если у вас достаточно места на диске, вы также можете использовать скрипт для записи сеанса входа в систему (например, сценарий устранения неполадок `date% m% d% y`). Если у вас нет возможности сохранять логи, записывайте все, что вы делали и что видели. Вы можете не вспомнить все это позже, особенно если вы находитесь в состоянии стресса. Вы можете помнить шаги, но не порядок, в котором вы их выполняли.
После устранения проблемы задокументируйте, что произошло. Возможно данная проблема возникнет снова, и вам, возможно, придется объяснить своему руководству или клиентам, что произошло, и как вы собираетесь предотвратить это в будущем. По возможности подумайте, как можно избежать данной проблемы в будущем. Можете ли вы улучшить свои службы мониторинга так, чтобы проблемы с дисковым пространством, памятью и сетью, изменения конфигурации и т. д. были решены задолго до того, как они повлияют на работающие службы?
В инфраструктуре любого предприятия есть очень много требующих внимания деталей. Например, места для серверов, среды разработки, безопасность, стеки программного обеспечения, обновления программного обеспечения, обслуживание оборудования, что все затраты на обслуживание платформы, как правило, огромны. Компаниям, которые разрабатывают и развертывают приложения, необходимо выделить много ресурсов для поддержания работы платформы - ресурсов, которые в противном случае можно было бы использовать для разработки программного обеспечения.
Поэтому возникла необходимость в облачных платформах. Эти решения используют модель облачных вычислений, чтобы предоставить разработчикам все необходимое для выполнения их работы - от сред разработки на хостах и инструментов баз данных до полных возможностей управления приложениями. Разработчики, работающие в облачной платформе, имеют доступ ко всем ресурсам, необходимым для создания, развертывания и запуска программных приложений. Для больших компаний облачная платформа может обеспечить масштабируемую базу для новых приложений, которые необходимо предоставлять в короткие сроки. При использовании модели "плати по мере роста" нет необходимости в долгосрочных инвестициях в локальные платформы.
Почему "опенсорс"?
Теперь, когда мы заявили о преимуществах облачных вычислений перед традиционными платформами, следующий вопрос заключается в том, почему облачная платформа с открытым исходным кодом является лучшим вариантом, чем запатентованная облачные решения. Самый очевидный ответ - стоимость: лицензии на проприетарные решения всегда предполагают более затратные вложения. Еще одним важным преимуществом является гибкость и свобода выбора из самых разнообразных структур, облаков и услуг.
Платные платформы, с другой стороны, могут привязать вас к инструментам и услугам, которыми они владеют. В обмен они предлагают определенные преимущества, такие как соблюдение соглашения об уровне обслуживания (SLA) и освобождение от препятствий, таких как тестирование и интеграция, но эти преимущества едва ли перевешивают преимущества открытости.
Ниже представлен список облачных платформ с открытым исходным кодом для предприятий, которые сегодня пользуются популярностью на рынке.
Cloud Foundry
Созданный компанией VMWare затем приобретённый компанией Pivotal Software, Cloud Foundry отличается тем, что он доступен как автономное приложение с открытым исходным кодом, что делает его независимым от поставщика. Его можно развернуть в VMware vSphere или других облачных инфраструктурах, таких как HP Helion, Azure или AWS. Или даже можно самостоятельно разместить его на сервере OpenStack.
Благодаря использованию пакетов сборки Cloud Foundry упрощает поддержку среды выполнения и инфраструктуры. При каждой компиляции приложения Cloud Foundry Application Runtime выбирает наиболее удобный для него пакет сборки. Затем buildpack занимается компиляцией приложения и подготовкой его к запуску.
Cloud Foundry разработана для быстрой разработки и развертывания приложений с помощью высокомасштабируемой архитектуры и удобных для DevOps рабочих процессов. Эта технология наряду с другим языками так же, поддерживает языки, как Python, Ruby, PHP, Java и Go. Тем не менее, чтобы правильно вписаться в Cloud Foundry, рекомендуется, чтобы ваш проект соответствовал 12-факторному стандарту приложений - методологии, специально разработанной для разработки оптимальных приложений SaaS.
WSO2
Если часто работаете над сервис-ориентированной архитектурой (SOA), то скорее всего у вас есть большое количество внутренних и внешних API. Это тот сценарий, когда WSO2 в большей степени проявляет себя благодаря своему API-менеджеру, способному обрабатывать весь цикл API от начала до конца. WSO2 обеспечивает соответствие большинству требований, которые могут быть выдвинуты клиентами, включая управление версиями, документацию API и разгрузку SSL.
WSO2 использует концепцию магазина, в которой разработчики могут находить, пробовать и оценивать API. Развертывание является простым и простым, предоставляя множество опций для управления потоком API. Он также предоставляет функцию автоматического восстановления в случае приостановки работы конечной точки. Все эти качества направлены на сокращение времени вывода на рынок, упрощение управления затратами и, в целом, повышение гибкости бизнес-процессов.
Большим плюсом WSO2 API Manager является его простая интеграция с WSO2 Identity Server - решением IAM (Identity and access manager), управляемым API. Эта интеграция предлагает удобную платформу для аутентификации в облачных средах.
Cloudify
Cloudify - это фреймворк оркестрации, предназначенная для моделирования приложений и услуг при автоматизации их жизненных циклов. Фреймворк включает в себя возможность развертывания в любой облачной среде или центре обработки данных. Он также предлагает инструменты для мониторинга всех аспектов развернутых приложений, определения условий отказа и их решения вручную или автоматически.
Одной из наиболее заметных особенностей Cloudify является моделирование проекта на основе TOSCA. Это нововведение позволяет разработчикам использовать YAML для создания чертежей топологий приложения. YAML - считываемый человеком язык сериализации данных, используемый для написания определений на основе спецификации TOSCA, что даёт разработчикам стандартизированный способ описания взаимосвязей между приложениями, системами и компонентами облачной инфраструктуры.
Облачная оркестрация Cloudify обеспечивает прочную базу для управления ИТ и обеспечения безопасности, позволяя пользователям применять ограничения доступа с различными ролями и уровнями разрешений. Для общения с внешними сервисами, такими как контейнеры Kubernetes, облачные сервисы (AWS, Azure, vSphere, OpenStack) и инструменты управления конфигурацией (Pucket, Anulable, Chef), Cloudify использует свой набор официальных плагинов, в то время как многие другие сервисы работают с существующими плагинами.
OpenShift
OpenShift - платформа на базе Kubernetes, с гибким и очень быстрым установщиком и поддержкой большого числа API, что позволяет разработчикам расширять платформу, исходя из своих потребностей. Он построен с учетом безопасности, что иллюстрируется примером: контейнеры должны запускаться от имени обычных пользователей, и когда это не так, OpenShift требует явного переопределения для запуска контейнера.
Использование Kubernetes требует значительного количества серверов, и для его освоения требуется определенное обучение. Именно поэтому эта платформа не подходит для небольших проектов, если в ближайшем будущем она не превратится в более масштабный проект.
Пользователи OpenShift подчеркивают возможность его быстрой установки и настройки, а также простоту обслуживания модулей и надстроек. Еще один плюс - факт наличия собственного Git репозитория. В противовес этому имеется некая сложность в чтении и интерпретации логов. В частности, когда происходит сбой при загрузке проекта, трудно понять, где проблема.
Tsuru
Rede Globo, вторая по величине коммерческая телесеть во всем мире, запустила Tsuru как продукт на базе Docker PaaS (платформа как сервис), способный организовывать и запускать приложения в производственной среде. Это платформа с открытым исходным кодом, поддерживающая сайты с миллионами пользователей, разработанная компанией Globo.com.
Пользователи Tsuru утверждают, что это существенно улучшает время вывода на рынок, не отказываясь от простоты, высокой доступности, безопасности или стабильности. Его можно запускать на различных облачных инфраструктурах, будь то публичная или частная, при условии, что они поддерживаются Docker-машинами. Также он поддерживает практически все известные язык программирования, что даёт разработчикам свободу выбора в соответствии с их предпочтениями.
С помощью Tsuru можно использовать различные хранилища данных, включая базы данных SQL или NoSQL, или альтернативы в памяти, такие как Memcached или Redis. Чтобы управлять приложением, вы можете выбрать один из своих предпочтений и подключить его к приложению. Чтобы управлять приложением, вы можете выбрать между использованием командной строки или веб-интерфейсом, а затем развернуть через Git. Инфраструктура Tsuru займется всеми рутинными делами.
Stackato
Stackato - это полиглотный продукт PaaS, основанный на Cloud Foundry и Docker, который работает поверх облачной инфраструктуры и служит платформой для запуска приложений. Пользователи Stackato говорят, что он предоставляет гибкую и надежную платформу приложений, которая помогает повысить производительность как администраторов облачных вычислений, так и разработчиков. Он хорошо подходит для развертывания корпоративных облачных сред, сочетая гибкость непосредственного доступа к виртуальной машине в облачной инфраструктуре с автоматизированной конфигурацией, обеспечиваемой полнофункциональной системой PaaS. Среди поддерживаемых облачных инфраструктур можно показать HP Cloud Services, Citrix XenServer, AWS, OpenStack, VMware.
В Stackato у каждого приложения есть свой контейнер Linux (LXC), который гарантирует эффективное и безопасное совместное использование ресурсов. Его спектр услуг состоит из Helion Control Plane, который Stackato использует для связи с основным облаком и управления всем циклом услуг; Helion Service Manager - хранилище дополнительных служб, доступных для приложений; Helion Cloud Foundry - гибкая среда выполнения, предназначенная для упрощения хостинга и разработки приложений; Helion Code Engine, сервис непрерывной доставки, интегрированный с репозиториями Git, частными или публичными, и Helion Stackato Console, веб-интерфейс для управления всеми функциями Helion Cloud.
Alibaba
Хотя и сложно представить компанию Alibaba в числе облачных платформах с открытым исходным кодом и PaaS, бизнес Alibaba Cloud Computing растет быстрыми темпами. Она уже завоевала 50% китайского рынка облачных технологий, а также удачно обслуживает рынки за пределами Китая. Например, они начинают оказывать биллинговую поддержку в долларах США по 168 странам и разрабатывать услуги, специально предназначенные для зарубежных рынков.
Сервисы облачных платформ, включенные в предложение Alibaba, включают множество бесплатных функций, включая контейнерные сервисы для Docker и Kubernetes, Container Registry, Auto Scaling и DataWorks, защищенную среду для разработки данных в автономном режиме. Его службы хорошо задокументированы и предоставляют все необходимое, чтобы сразу начать перенос приложений в облако, в том числе много обучающих видеороликов. Следуя нескольким простым шагам и не инвестируя ни цента, Alibaba обеспечивает развертывание приложения в кратчайшие сроки.
Заключение
К счастью для всех разработчиков, облачные технологии становятся более доступными. Пару лет назад, конкурируя за контейнерные технологии (Docker, Kubernetes, Mesos, Nomad, ECS, назовем несколько) угрожали разделить рынок на изолированные отсеки, создавая значительные риски всякий раз, когда нужно было выбрать платформу. Но, несмотря на то, что в наши дни на выбор предоставляются все больше платформ, различия между сегодняшними вариантами с открытым исходным кодом заключаются только в деталях: разных схемах затрат, разных инструментах управления, разных подходах к безопасности. Другими словами, если выбирали одну облачную платформу с открытым исходным кодом и вас она не устраивает, легко можете перейти к другой, не обременяя себя расходами.
В зависимости от технической задачи вы можете выбрать платформу, которая лучше отвечает вашим потребностям и позволяет забыть о таких проблемах, как емкость сервера, промежуточное программное обеспечение, платформы, виртуальные машины, хранилища данных и т.д. После того, как вы освободитесь от всего этого, вы сможете вложить все свои ресурсы и все свое внимание в одно, что действительно важно для вас: как можно быстрее сделать доступным приложение пользователям.
В этой статье расскажем что такое хеш, хеширование и рассмотрим какие есть алгоритмы хеширования.
Что такое хеширование? Хеширование означает использование некоторой функции или алгоритма для сопоставления данных объекта с некоторым репрезентативным целочисленным значением. Результат этой функции известен как хеш-значение или просто хэш (hash). Хорошая хеш-функция использует алгоритм одностороннего хеширования, или, другими словами, хэш нельзя преобразовать обратно в исходный ключ.
Обеспечение того, чтобы данные не изменялись (модифицировались) во время передачи, очень важно, и чтобы помочь нам определить, сохраняется ли целостность сообщения, мы можем использовать алгоритмы хеширования. Алгоритмы хеширования предназначены для получения входных данных, например, строки текста или файла, а затем использования односторонней функции для создания дайджеста. Дайджест (digest) - это хеш-представление ввода, и его нельзя отменить. Каждый уникальный файл или сообщение генерирует уникальное хеш-значение (дайджест). Это означает, что, если данные каким-либо образом изменены, значение хеш-функции будет однозначно другим.
На следующем рисунке показан процесс одностороннего хеширования:
Как этот процесс работает между устройствами? Представьте, что отправитель, хост A, хочет отправить сообщение на устройство назначения, хост B. Вместо того, чтобы хост A отправлял сообщение как есть, хост A создаст дайджест сообщения. Как только в дайджесте будет создано сообщение, хост A отправит и сообщение, и дайджест хосту B. На следующем рисунке показано, что хост A отправляет сообщение с дайджестом хосту B:
Когда хост B получает сообщение от источника, он также создает дайджест сообщения и сравнивает его с дайджестом, полученным от хоста A. Если оба значения хеш-функции (дайджесты) совпадают, это означает, что сообщение не было изменено во время передачи. Однако, если значения дайджеста различаются, это означает, что где-то по пути сообщение было изменено и, следовательно, содержимое сообщения не совпадает.
Возможно ли, что два разных файла будут иметь одинаковое хеш-значение? Хотя алгоритмы хеширования предназначены для создания уникального дайджеста для каждого уникального файла, в прошлом были случаи, что у двух разных файлов одно и то же значение хеш-функции. Это известно, как хэш-коллизия. Если произошла коллизия хеширования, это означает, что алгоритм хеширования, используемый во время процесса, уязвим, и ему не следует доверять. Однако некоторые из самых популярных алгоритмов хеширования, которые используются в настоящее время, подвержены коллизии хеширования.
Алгоритмы хеширования
Message Digest 5 (MD5) - это алгоритм хеширования, который создает 128-битный дайджест. Алгоритм MD5 был реализован во многих системах на протяжении многих лет и работал хорошо до тех пор, пока не произошла коллизия хеширования. Это сделало MD5 уязвимым алгоритмом хеширования, который больше не рекомендуется.
На следующем рисунке представлен процесс хеширования MD5:
Как показано на предыдущей диаграмме, сообщение отправляется алгоритму MD5, который затем преобразуется в 128-битный дайджест. Хотя MD5 все еще используется во многих системах, рекомендуется использовать более безопасную функцию, такую как Secure Hashing Algorithm 2 (SHA-2).
Еще одна хорошо известная функция хеширования - это Secure Hashing Algorithm 1 (SHA-1). Этот алгоритм хеширования был создан еще в 1990-х годах Национальным институтом стандартов и технологий (NIST). NIST разработал этот алгоритм с функциями, аналогичными MD5. Одним из основных преимуществ использования SHA-1 для проверки целостности является то, что он создает 160-битный дайджест любого сообщения или файла.
На следующем рисунке представлена функция SHA-1:
Хотя SHA-1 считается лучше, чем MD5, так как создает более крупный дайджест, он работает медленнее, чем MD5, и содержит уязвимости в самом алгоритме. Однако NIST разработал более новую версию, известную как SHA-2.
SHA-2 позволяет создавать дайджест с использованием битов большого размера, таких как:
SHA-224 (224 bit)
SHA-256 (256 bit)
SHA-384 (384 bit)
SHA-512 (512 bit)
Имейте в виду, что даже если вы знаете, что для проверки целостности сообщения использовалось хеширование, оно все равно уязвимо для атаки MiTM. Представьте, что источник отправляет сообщение с хеш-значением. Злоумышленник может перехватить сообщение, изменить его содержимое и пересчитать новый хэш перед его отправкой адресату. Чтобы помочь получателю проверить подлинность источника, нам нужно применить Hash Message Authentication Code (HMAC) к нашему процессу хеширования.
Чтобы добавить аутентификацию источника во время процесса хеширования, добавляется HMAC. HMAC - это секретный ключ, который объединяет входное сообщение с алгоритмом хеширования, таким как MD5 или SHA-1, для создания уникального дайджеста.
На следующем рисунке показано использование HMAC с функцией хеширования:
Поскольку этот секретный ключ (HMAC) используется только отправителем и предполагаемым получателем, значение выходного дайджеста будет просто зависеть от фактического входного сообщения (данных) и секретного ключа, используемого для применения дополнительного уровня безопасности для аутентификации источника. Поскольку источник и место назначения будут единственными сторонами, которые знают секретный ключ (значение HMAC), атака MiTM не будет успешной с точки зрения нарушения целостности любых сообщений, которые проходят через сеть.
На следующем скриншоте показан секретный ключ (HMAC), примененный к строке текста:
Как показано на предыдущем рисунке, текстовая строка (сообщение) была объединена с секретным ключом и обработана с использованием алгоритма хеширования MD5 и SHA-1 для создания уникального дайджеста.