#decommission datanode hadoop | Explore Tumblr posts and blogs

manasranjanmurlidharrana · 5 years ago

Text

How Mr. Manasranjan Murlidhar Rana Helped Union Bank Switzerland as a Certified Hadoop Administrator

Mr. Manasranjan Murlidhar Rana is a certified Hadoop Administrator and an IT professional with 10 years of experience. During his entire career, he has contributed a lot to Hadoop administration for different organizations, including the famous Union Bank of Switzerland.

Mr. Rana’s Knowledge in Hadoop Architecture and its Components

Mr. Manasranjan Murlidhar Rana has vast knowledge and understanding of various aspects related to Hadoop Architecture and its different components. These are MapReduce, YARN, HDFS, HBase, Pig, Flume, Hive, and Zookeeper. He even has the experience to build and maintain multiple clusters in Hadoop, like the production and development of diverse sizes and configurations.

His contribution is observed in the establishment of rack topology to deal with big Hadoop clusters. In this blog post, we will discuss in detail about the massive contribution of Manasranjan Murlidhar Rana as a Hadoop Administrator to deal with various operations of the Union Bank of Switzerland.

Role of Mr. Rana in Union Bank of Switzerland

Right from the year 2016 to until now, Mr. Manasranjan Murlidhar Rana played the role of a Hadoop Administrator with 10 other members for his client named Union Bank of Switzerland. During about 4 years, he worked a lot to enhance the process of data management for his client UBS.

1. Works for the Set up of Hadoop Cluster

Manasranjan Murlidhar Rana and his entire team were involved in the set up of the Hadoop Cluster in UBS right from the beginning to the end procedure. In this way, the complete team works hard to install, configure, and monitor the complete Hadoop Cluster effectively. Here, the Hadoop cluster refers to a computation cluster designed to store and analyze unstructured data in a well-distributed computational environment.

2. Handles 4 Different Clusters and Uses Ambari Server

Mr. Manasranjan Murlidhar Rana is responsible for handling four different clusters of the software development process. These are DEV, UAT, QA, and Prod. He and his entire team even used the innovative Ambari server extensively to maintain different Hadoop cluster and its components. The Ambari server collects data from a cluster and thereby, controls each host.

3. Cluster Maintenance and Review of Hadoop Log Files

Mr. Manasranjan Murlidhar Rana and his team have done many things to maintain the entire Hadoop cluster, along with commissioning plus decommissioning of data nodes. Moreover, he contributed to monitoring different software development related clusters, troubleshoot and manage the available data backups, while reviewed log files of Hadoop. He also reviewed and managed log files of Hadoop as an important of the Hadoop administration to communicate, troubleshoot, and escalate tons of issues to step ahead in the right direction.

4. Successful Installation of Hadoop Components and its Ecosystem

Hadoop Ecosystem consists of Hadoop daemons. Hadoop Daemons in terms of computation imply a process operating in the background and they are of five types, i.e. DataNode, NameNode, TaskTracker, JobTracker, and Secondary NameNode.

Besides, Hadoop has few other components named Flume, Sqoop and HDFS, all of which have specific functions. Indeed, installation, configuration, and maintenance of each of the Hadoop daemons and Hadoop ecosystem components are not easy.

However, based on the hands-on experience of Mr. Manasranjan Rana, he succeeded to guide his entire team to install Hadoop ecosystems and its components named HBase, Flume, Sqoop, and many more. Especially, he worked to use Sqoop to import and export data in HDFS, while to use Flume for loading any log data directly into HDFS.

5. Monitor the Hadoop Deployment and Other Related Procedures

Based on the vast knowledge and expertise to deal with Hadoop elements, Mr. Manasranjan Murlidhar Rana monitored systems and services, work for the architectural design and proper implementation of Hadoop deployment and make sure of other procedures, like disaster recovery, data backup, and configuration management.

6. Used Cloudera Manager and App Dynamics

Based on the hands-on experience of Mr. Manasranjan Murlidhar Rana to use App Dynamics, he monitored multiple clusters and environments available under Hadoop. He even checked the job performance, workload, and capacity planning with the help of the Cloudera Manager. Along with this, he worked with varieties of system engineering aspects to formulate plans and deploy innovative Hadoop environments. He even expanded the already existing Hadoop cluster successfully.

7. Setting Up of My-SQL Replications and Maintenance of My-SQL Databases

Other than the expertise of Mr. Manasranjan Murlidhar Rana in various aspects of Bigdata, especially the Hadoop ecosystem and its components, he has good command on different types of databases, like Oracle, Ms-Access, and My-SQL.

Thus, according to his work experience, he maintained databases by using My-SQL, established users, and maintained the backup or recovery of available databases. He was also responsible for the establishment of master and slave replications for the My-SQL database and helped business apps to maintain data in various My-SQL servers.

Therefore, with good knowledge of Hadoop Ambari Server, Hadoop components, and demons, along with the entire Hadoop Ecosystem, Mr. Manasranjan Murlidhar Rana has given contributions towards the smart management of available data for the Union Bank of Switzerland.

Find Mr. Manasranjan Murlidhar Rana on Social Media. Here are some social media profiles:-

https://giphy.com/channel/manasranjanmurlidharrana https://myspace.com/manasranjanmurlidharrana https://mix.com/manasranjanmurlidhar https://www.meetup.com/members/315532262/ https://www.goodreads.com/user/show/121165799-manasranjan-murlidhar https://disqus.com/by/manasranjanmurlidharrana/

#Manasranjan Murlidhar Rana #Mr. Rana’s

1 note · View note

bigdataschool-moscow · 4 years ago

Text

Основы Hadoop HDFS для начинающих администраторов: как вывести узел из кластера без потери данных

При том, что Apache Hadoop – высоконадежная экосистема хранения и аналитики больших данных, отказы случаются и в ней. Сегодня в рамках обучения начинающих администраторов и разработчиков Hadoop разберем, какие типы сбоев возможны в распределенной файловой системе HDFS и механизмы их предупреждения, а также рассмотрим процедуру вывода узлов из кластера для их профилактического обслуживания и ремонта.

Точки отказа в Hadoop HDFS

Сперва напомним, что проект Hadoop состоит из 4-х основных модулей: Hadoop Common, MapReduce, YARN и HDFS. Именно распределённая файловая система HDFS (Hadoop Distributed File System) обеспечивает хранение файлов на узлах данных (DataNodes), адреса которых находятся на специальном мастер-сервере имен (NameNode). Таким образом, потенциальными точками отказа в HDFS являются NameNode и DataNodes. Однако HDFS включает механизмы предупреждения сбоев на этих узлах и средства смягчения их последствий.

Резервирование NameNode

NameNode - это главный узел, который хранит такие метаданные, как имя файла, количество блоков, количество реплик, расположение и идентификаторы блоков. В первой версии Hadoop узел NameNode был единственной точкой отказа, т.к. даже при сохранении всех метаданных на диске, время их восстановления было очень велико (около 30 минут). 2-я версия Apache Hadoop с механизмами высокой доступности решает эту проблему за счет резервирования NameNode путем дублирования. Одномоментно активен только один мастер-узел, при выходе из строя которого ответственность за обслуживание клиентов сразу же переходит к резервному серверу имен. Такое единственное лидерство NameNode обеспечивается одним из 2-х способов:- Quorum Journal Manager (QJM) для хранения edit-логов, где права на запись данных имеет только активный NameNode, а резервный мастер-узел может только читать; - общее хранилище, в котором активный мастер-узел изменяет информацию edit-логов, а резервный NameNode – ищет эти изменения. Если NameNode выходит из строя, он прекращает доступ к этому общему хранилищу. Активный и резервный мастер-узлы всегда синхронизированы друг с другом и имеют одинаковые метаданные, совместно используя высокодоступное общее хранилище логов. Резервный NameNode читает общий edit-log, чтобы синхронизировать свое состояние с активным мастер-узлом.Узлы данных отправляют отчеты о блоках HDFS в оба NameNode, потому что отображения блоков хранятся в памяти мастер-узла, а не на диске. Резервный мастер-узел периодически принимает контрольные точки пространства имен активного NameNode . Таким образом, благодаря резервированию отказ системы Hadoop из-за выхода из строя мастер-узла маловероятен и возможен только в случае одновременного сбоя на обоих NameNode, что случается редко. Примечательно, что в свежем релизе Apache Hadoop 3.3.1, выпущенном в июне 2021 года, можно запускать сразу несколько резервных NameNode, что еще более увеличивает надежность и отказоустойчивость всего кластера. Подробнее об этом читайте в нашей новой статье.

Реплицирование на узлах данных

В HDFS для предотвращения сбоя и потери данных на Data Nodes используется репликация, когда один блок данных хранится в нескольких местах. По умолчанию коэффициент репликации для HDFS равен 3, т.е. для исходного блока данных будет две копии (реплики).По умолчанию Hadoop размещает первую реплику на том же узле, а вторую - на другой стойке кластера, выбранной случайным образом. Третья копия размещается на той же стойке, что и вторая, но на другом узле. Дальнейшие реплики размещаются на случайных узлах кластера, распределенных по разным стойкам. По умолчанию DataNode непрерывно отправляет контрольные сигналы (heartbeat) на NameNode каждые 3 секунды. Если NameNode не получает heartbeat-сигнал от узла данных в течение 10 минут (тайм-аут по умолчанию), то мастер-узел посчитает этот сервер данных неработоспособным, проверит доступность данных в нем и инициирует репликацию. Таким образом, если один DataNode выйдет из строя, мастер-узел предоставит адрес реплики данных . Это практически полностью исключает сбой Big Data системы из-за отказа DataNode, т.к. одновременный выход из строя всех узлов кластера, где хранятся реплики данных, крайне маловероятен. На первый взгляд, такая стратегия горячей репликации исключает возможность профилактического ремонта или обслуживания серверов, однако, это не так. Как администратор может вывести узел из эксплуатации, не потеряв данные, мы расскажем далее.

Обслуживание узлов в кластере Hadoop: на заметку администратору

NameNode хранит актуальные сведения не только о состоянии узлов данных в плане их живучести, а также содержит информацию об эксплуатации узла, чтобы администратор кластера знал, какие сервера работают, а какие - выведены из эксплуатации или находится на сервисном обслуживании. Таким образом, с точки зрения эксплуатации узел может находиться в одном из следующих состояний (adminState) :- NORMAL - в эксплуатации; - DECOMMISSIONED – выведен из эксплуатации; - DECOMMISSION_INPROGRESS – перевод в состояние DECOMMISSIONED; - IN_MAINTENANCE – на сервисном обслуживании; - ENTERING_MAINTENANCE – перевод в состояние обслуживания. Когда администратор кластера Hadoop выводит из эксплуатации DataNode, он сначала переводится в состояние DECOMMISSION_INPROGRESS. После то��о, как все блоки данных на этом узле будут полностью реплицированы в другом месте на основе заданного коэффициента репликации каждого блока, DataNode переходит в состояние DECOMMISSIONED. Теперь администратор кластера Hadoop может выключить узел для выполнения долгосрочного ремонта или профилактического обслуживания. А после проведения этих операций, сервер можно снова включить в кластер.Иногда нужно отключить узел данных на несколько минут или пару часов для краткосрочного ремонта или обсл��живания, не выполняя полную репликацию блоков HDFS. Когда администратор переводит сервер в состояние обслуживания (IN_MAINTENANCE), он сперва переходит в состояние ENTERING_MAINTENANCE. Пока все блоки HDFS на этом узле данных, минимально реплицируются в другом месте, DataNode будет немедленно переведен в состояние IN_MAINTENANCE. По завершении сервисных операций администратор может вручную вывести узел из состояния обслуживания или с помощью настроенного тайм-аута, который позволяет задать максимальную продолжительность нахождения узла в статусе IN_MAINTENANCE. По истечении этого тайм-аута DataNode автоматически перейдет в NORMAL без вмешательства человека. Таким образом, сервисные операции, которые может выполнить администратора кластера Hadoop относительно узла данных, включают следующее: - вывод из эксплуатации; - повторное включение в кластер; - перевод в состояние обслуживания; - вывод из состояния обслуживания. Чтобы провести любую из этих операций, администратор кластера Hadoop должен выполнить два шага: - обновите файлы конфигурации на уровне хоста, чтобы указать желаемое состояние целевых серверов. - Запустить команду hdfs dfsadmin , чтобы мастер-узел NameNode перезагрузил файлы конфигурации уровня хоста. По умолчанию NameNode поддерживает только вывод из эксплуатации и повторное включение узла в кластер, игнорируя операции администрирования, связанные с обслуживанием. Информация о работающих хостах прописывается в файле dfs.hosts, а о выведенных из эксплуатации, например, с целью профилактического обслуживания или ремонта, в файле dfs.hosts.exclude. При этом выведенные узлы отмечены как в файле dfs.hosts, так и в dfs.hosts.exclude. При этом есть два формата файлов конфигурации, основанных на разных факторах : - имя хоста, где каждая строка включает имя хоста/IP-адрес узла данных. Это формат по умолчанию. - JSON-конфигурация, где каждый элемент отображается на один узел данных, и каждый узел данных может иметь несколько свойств. Именно этот новый формат конфигурации используется для перевода узлов в состояние обслуживания. Таким образом, JSON-формат конфигурации поддерживает общие свойства узлов данных и позволяет администратору Hadoop-кластера провести сервисные операции с DataNode. Например, хосты узлы host1 и host2 находятся в рабочем состоянии, host3 выведен из эксплуатации, а host4 переведен в состояние обслуживания. Тогда JSON-конфигурация этих узлов будет выглядеть так.Поскольку за отслеживание состояний узлов данных отвечает NameNode, при проведении сервисных операций с DataNode, администратору Hadoop придется поработать с настройками мастер-узла. Для большинства случаев подойдут значения по умолчанию, заданные в файле hdfs-default.xml, но иногда может потребоваться изменить следующие параметры : - dfs.namenode.maintenance.replication.min - минимальный коэффициент репликации рабочего блока данных HDFS в случае режима обслуживания, по умолчанию равен 1; - dfs.namenode.decommission.interval – периодичность, с которой NameNode проверяет завершение вывода узлов данных из эксплуатации или состояния обслуживания. По умолчанию равен 30 секунд, другие единицы времени (минуты, часы и пр.) задаются в конфигурации heartbeat.interval. Без дополнительного указания единиц времени используются секунды. - dfs.namenode.decommission.blocks.per.interval - приблизительное количество блоков HDFS для обработки за интервал вывода из эксплуатации или состояния обслуживания, определенном в namenode.decommission.interval. По умолчанию равен 500000. - dfs.namenode.decommission.max.concurrent.tracked.nodes - максимальное количество узлов данных в состояниях DECOMMISSION_INPROGRESS или ENTERING_MAINTENANCE, которые одновременно сможет отслеживать NameNode, т.к. это потребляет дополнительную память, пропорциональную количеству блоков HDFS на узле данных. Ограничение этого предела снижает риски при выводе большого количества узлов. По умолчанию этот параметр равен 100, а значение 0 означает отсутствие ограничений. В следующий раз мы продолжим разговор про основы Hadoop и рассмотрим потенциальные точки отказа на другом core-компоненте этой Big Data платформы – системе YARN, а также способы их обхода. А практически освоить все тонкости администрирования и эксплуатации Apache Hadoop вам помогут специализированные курсы в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве: - Основы Hadoop - Администрирование кластера Hadoop - Hadoop для инженеров данных Источники 1. https://karthiksharma1227.medium.com/different-types-of-failures-in-hadoop-48163a021d6 2. https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HdfsDataNodeAdminGuide.html 3. https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/hdfs-default.xml Read the full article

#BigData #Hadoop #HDFS #администрирование #архитектура #Большиеданные

0 notes