Chuyện của sys

DevOps Blog

[BIGDATA] Apache KafKa July 29, 2017

  1. Giới thiệu Apache Kafka

+ Kafka: hệ thống hàng đợi dữ liệu (message queue) phục vụ chức năng thu thập dữ liệu đầu vào (stream ingestion system).
+ Kafka là một hệ thống xử lý hàng đợi theo cơ chế publish-subscribe; Kafka còn hỗ trợ triển khai hệ thống thu thập log theo mô hình phân tán (distribute), phân chia (partition), và đồng bộ (replicate). Mã nguồn Kafka được thiết kế cho việc xử lý dữ liệu lớn khi đọc/ghi dữ liệu, giảm độ trễ trong quá trình truyền tải dữ liệu.
+ Kafka có thể hiểu là một hệ thống logging, nhằm lưu lại các trạng thái của hệ thống, nhằm phòng tránh mất thông tin.
 2. Kiến trúc tổng quan về Apache Kafka

  • Kafka lưu, phân loại message theo topics
  • Kafka sử dụng producers để publish message vào các topics ở trên
  • Kafka sử dụng consumers để subscribe vào topics, sau đó xử lý các message lấy được theo một logic nào đó
  • Kafka thường được chạy dưới dạng cluster, khi đó mỗi server trong đó sẽ được gọi là broker.

Topic

Topic có thể hiểu là một ngôn ngữ chung giữa producer (người nói) và consumer (người nghe, sử dụng).
Với mỗi topic, kafka sẽ duy trì thông qua partitioned log như dưới đây:

+ Mỗi partition là một chuỗi log, có thứ tự và không thể thay đổi (immutable).
+ Mỗi message trong partition sẽ có id tăng dần , gọi là offset
Về cách chọn partition number cho tốt, có thể tham khảo ở link : http://blog.confluent.io/2015/03/12/how-to-choose-the-number-of-topicspartitions-in-a-kafka-cluster/
+ Kafka cluster sẽ lưu lại mọi message đã được published, cho dù message đó đã được/chưa được sử dụng (consume). Thời gian lưu message có thể tuỳ chỉnh được thông qua log retention.
Một điểm thú vị là Consumer sẽ điều khiển những gì mình muốn đọc thông qua offset của message, hay thậm chí là thứ tự đọc. Consumer có thể reset lại vị trí của offset để re-process lại một vài message nào đó.

Producer

Như đã nói ở trên, producer nhằm mục đích chính là ném message vào topic. Cụ thể hơn là producer có nhiệm vụ là chọn message nào, để ném vào partition nào trong topic. Nhiệm vụ này rất quan trọng, giúp cho kafka có khả năng “scale” tốt.

Consumer

Thông thường thì một hệ thống messaging sẽ có 2 loại

  • Queue: Một message sẽ được xử lý bởi một consumer
  • Pub/Sub: Một message sẽ được xử lý bởi một vài consumer thích hợp, tuỳ theo topic

Ở kafka chúng ta có một khái niệm gọi là consumer group giúp chúng ta có thể làm được đồng thời cả 2 loại trên, rất thú vị. Việc subscribe một topic sẽ được thực hiện bởi consumer group. Mỗi một message sẽ được gửi cho duy nhất  một consumer instance trong một consumer group. Việc này dấn đến điều gì?

  • Nếu nhiều instance consumer có cùng group: chúng ta sẽ có một hệ thống queue
  • Nếu mỗi instance là một group, chúng ta sẽ có một hệ thống pub/sub

Kafka đảm bảo

  • Message được gửi bởi producer đến một topic partition nào đó sẽ được đảm bảo thứ tự , thông qua offset
  • Consumer instance sẽ nhìn thấy  message theo đúng thứ tự trong log

3. So sánh apache kafka với rabbitMQ

RabbitMQ
What it is? RabbitMQ is a solid, mature, general purpose message broker that supports several standardized protocols such as AMQP Apache Kafka is a message bus optimized for high-ingress data streams and replay
Primary use High-throughput and reliable background jobs, communication and integration within, and between applications. Build applications that process and re-process streamed data on disk
License Open Source: Mozilla Public License Open Source: Apache License 2.0
Written in Erlang Scala (JVM)
Client libraries Many mature libraries, including: Ruby, Python, Node.js, Clojure, Go, Java and C Many, including: Ruby, Python, Node.js and Java
Support for HA Yes Yes
Federated queues Yes No
Complex routing scenarios Yes No
Scaling strategies Mostly vertical Built from the ground up with horizontal scaling in mind
Hosted solution & Enterprise Support Available from CloudAMQP Available fromCloudKarafka

4. Cài đặt & cấu hình:
Có thể tham khảo document bên dưới

  • https://www.dropbox.com/s/9omnnckwiqeq6sd/KAFKA.docx?dl=0

5. Một số site tham khảo về các vấn đề Apache Kafka

  • https://dzone.com/articles/understanding-kafka-consumer-groups-and-consumer-l
  • https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Controller+Internals
  • https://anturis.com/blog/apache-kafka-an-essential-overview/
  • http://codingpearls.com/big-data/apache-spark/xay-dung-mot-realtime-dashboard-su-dung-spark-streaming-kafka-nodejs-va-mongodb.html

 
 

Read more...[BIGDATA] Apache KafKa
No Comments on [BIGDATA] Apache KafKa
Categories: Tài liệu

[BIGDATA] Apache SPARK

1.Giới thiệu về Apache Spark

   + Apache Spark là một framework mã nguồn mở tính toán cụm, được phát triển sơ khởi vào năm 2009 bởi AMPLab . Sau này, Spark đã được trao cho Apache Software Foundation vào năm 2013 và được phát triển cho đến nay.

+ Tốc độ xử lý của Spark có được do việc tính toán được thực hiện cùng lúc trên nhiều máy khác nhau. Đồng thời việc tính toán được thực hiện ở bộ nhớ trong (in-memories) hay thực hiện hoàn toàn trên RAM.
+ Spark cho phép xử lý dữ liệu theo thời gian thực, vừa nhận dữ liệu từ các nguồn khác nhau đồng thời thực hiện ngay việc xử lý trên dữ liệu vừa nhận được ( Spark Streaming).
+ Spark không có hệ thống file của riêng mình, nó sử dụng hệ thống file khác như: HDFS, Cassandra, S3,…. Spark hỗ trợ nhiều kiểu định dạng file khác nhau (text, csv, json…) đồng thời nó hoàn toàn không phụ thuộc vào bất cứ một hệ thống file nào.

 
+ Spark cho phép xây dựng và phân tích nhanh các mô hình dự đoán. Hơn nữa, nó còn cung cấp khả năng truy xuất toàn bộ dữ liệu cùng lúc, nhờ vậy ta không cần phải lấy mẫu dữ liệu – đòi hỏi bởi các ngôn ngữ lập trình như R. Thêm vào đó, Spark còn cung cấp tính năng streaming, được dùng để xây dựng các mô hình real-time bằng cách nạp toàn bộ dữ liệu vào bộ nhớ.
+ Khi có một tác vụ nào đó quá lớn mà không thể xử lý trên một laptop hay một server, Spark cho phép ta phân chia tác vụ này thành những phần dễ quản lý hơn. Sau đó, Spark sẽ chạy các tác vụ này trong bộ nhớ, trên các cluster của nhiều server khác nhau để khai thác tốc độ truy xuất nhanh từ RAM. Spark sử dụng API Resilient Distributed Dataset (RDD) để xử lý dữ liệu.
2. Kiến trúc Apache Spark

+ Spark có kiến trúc gồm một node master và nhiều node worker dưới sự điều khiển của  master. Spark Driver sẽ  liên hệ với master node để điều phối các worker node nơi có chứa các excutor đang thực thi job.
+ Master node chứa chương trình điều khiển (Spark Standalone / YARN/ MESSO), các worker node, chương trình lập lịch sẽ chịu trách nhiệm lập lịch cho các tác vụ và yêu cầu các worker node thực hiện. Mỗi worker bao gồm một hoặc một số Excutor thực hiện việc lưu trữ, đọc ghi khi xử lý dữ liệu. Mỗi excutor chịu trách nhiệm xử lý các task nhỏ riêng biệt bằng các luồng độc lập.

3. Quản lý bộ nhớ của Apache Spark
+ Xét về khía cạnh memory, Spark giải quyết các vấn đề vấn đề xung quanh định nghĩa Resilient Distributed Datasets (RDDs). RDDs hỗ trợ hai kiểu thao tác thao tác: transformations và action..Thao tác chuyển đổi(tranformation) tạo ra dataset từ dữ liệu có sẵn. Thao tác actions trả về giá trị cho chương trình điều khiển (driver program) sau khi thực hiện tính toán trên dataset.
+ Spark thực hiện đưa các thao tác RDD chuyển đổi vào DAG (Directed Acyclic Graph) và bắt đầu thực hiện. Khi một action được gọi trên RDD, Spark sẽ tạo DAG và chuyển cho DAG scheduler. DAG scheduler chia các thao tác thành các nhóm (stage) khác nhau của các task.
+ Mỗi Stage bao gồm các task dựa trên phân vùng của dữ liệu đầu vào có thể pipline với nhau và có thể thực hiện một cách độc lập trên một máy worker. DAG scheduler sắp xếp các thao tác phù hợp với quá trình thực hiện theo thời gian sao cho tối ưu nhất.
Ví dụ: các thao tác map sẽ được đưa vào cùng một stage do không xảy ra shuffle dữ liệu giữa các stage. Kết quả cuối cùng của DAG scheduler là một tập các stage. Các Stages được chuyển cho Task Scheduler. Task Scheduler sẽ chạy các task thông qua cluster manager (Spark Standalone/Yarn/Mesos). Task scheduler không biết về sự phụ thuộc của các stages. Nó chỉ chịu trách nhiệm thực hiện sắp xếp các task một cách tối ưu nhất.
+ Mỗi Worker bao gồm một hoặc nhiều Excutor. Các excutor chịu trách nhiệm thực hiện các task trên các luồng riêng biệt. Việc chia nhỏ các task giúp đem lại hiệu năng cao hơn, giảm thiểu ảnh hưởng của dữ liệu không đối xứng (kích thước các file không đồng đều).

4. Thành phần của Apache Spark

Thành phần trung gian của Spark là Spark Core: cung cấp những chức năng cơ bản nhất của Spark như lập lịch cho các tác vụ, quản lý bộ nhớ, fault recovery, tương tác với các hệ thống lưu trữ…Đặc biệt, Spark Core cung cấp API để định nghĩa RDD (Resilient Distributed DataSet) là tập hợp của các item được phân tán trên các node của cluster và có thể được xử lý song song.
Spark có thể chạy trên nhiều loại Cluster Managers như Hadoop YARN, Apache Mesos hoặc trên chính cluster manager được cung cấp bởi Spark được gọi là Standalone Scheduler.

  • Spark SQL cho phép truy vấn dữ liệu cấu trúc qua các câu lệnh SQL. Spark SQL có thể thao tác với nhiều nguồn dữ liệu như Hive tables, Parquet, và JSON.
  • Spark Streaming cung cấp API để dễ dàng xử lý dữ liệu stream,
  • MLlib Cung cấp rất nhiều thuật toán của học máy như: classification, regression, clustering, collaborative filtering…
  • GraphX là thư viện để xử lý đồ thị.
  • Một trong những lý do khiến Spark chạy nhanh hơn Hadoop MapReduce đó là ở mỗi tác vụ dữ liệu được nạp lên bộ nhớ và xử lý ở đó, những tác vụ sau có thể sử dụng dữ liệu nằm trên bộ nhớ thay vì phải đọc ghi liên tục vào HDFS như Hadoop MapReduce (xem minh họa phía dưới)

 Hadoop MapReduce

Spark

5.Tại sao nên sử dụng Apache Spark

  Những tính năng nổi bật

  • “Spark as a Service”: Giao diện REST để quản lí (submit, start, stop, xem trạng thái) spark job, spark context
  • Tăng tốc, giảm độ trễ thực thi job xuống mức chỉ tính bằng giây bằng cách tạo sẵn spark context cho các job dùng chung.
  • Stop job đang chạy bằng cách stop spark context
  • Bỏ bước upload gói jar lúc start job làm cho job được start nhanh hơn.
  • Cung cấp hai cơ chế chạy job đồng bộ và bất đồng bộ
  • Cho phép cache RDD theo tên , tăng tính chia sẻ và sử dụng lại RDD giữa các job
  • Hỗ trợ viết spark job bằng cú pháp SQL
  • Dễ dàng tích hợp với các công cụ báo cáo như: Business Intelligence, Analytics, Data Integration Tools

     Nhờ triển khai Coordination Framework Apache ZooKeeper – cung cấp giải pháp quản lý, điều phối giao tiếp giữa các hệ thống phân tán (distributed systems) – mà Spark Server được đảm bảo tính sẵn sàng (high availability) theo mô hình active – active (load-balancing)

  Những điểm sáng giá ngoài tốc độ tính toán nhanh của Spark

     Sự đơn giản: Một trong những chỉ trích thường gặp ở Hadoop đó là sự phức tạp trong qúa trình phát triển, mặc dù đây là một trong những phương pháp tính toán đơn gỉan và hiệu qủa gíup tăng tốc độ xử lý của hệ thống. Thay vì đòi hỏi người dùng phải hiểu rạch ròi về MapReduce và lập trình Java, Spark sinh ra để gíup mọi người tiếp cận với công nghệ tính toán song song dễ dàng hơn rất nhiều. Người dùng chỉ cần một vài kiến thức cơ bản về database cộng với lập trình Python hay Scala là có thể sử dụng được.
     Độc lập với các nhà cung cấp dịch vụ Hadoop: Hầu hết các nhà cung cấp dịch vụ Hadoop đều hỗ trợ Spark. Điều này có nghĩa Spark không phụ thuộc vào các nhà cung cấp này. Nếu bạn muốn thay đổi nhà cung cấp dịch vụ, ta chỉ cần đem hệ thống Spark qua nhà cung cấp mới mà không lo ngại việc mất mát thông tin.
+ Theo một so sánh, năm 2013 Hadoop sử dụng cluster bao gồm 2100 máy và mất 72 phút để sắp xếp 100 TB dữ liệu, trong khi Spark cần số lượng máy bằng 1/10 nhưng sắp xếp chỉ mất 23 phút. Trong nhiều trường hợp Spark có thể chạy nhanh hơn từ 30-50 lần so với Hadoop MapReduce.

Để thấy được bức tranh toàn cảnh về Spark, hãy cùng xem một số thống kê:
+ Trong các thư viện mà Spark cung cấp thì có 69% người dùng Spark SQL, 62% sử dụng DataFrames, Spark Streaming và MLlib + GraphX là 58%

Lập trình viên có thể viết các ứng dụng Spark bằng nhiều ngôn ngữ khác nhau. Năm 2014, 84% người dùng sử dụng Scala, trong khi Java và Python cùng là 38% (Người dùng có thể sử dụng nhiều hơn 1 ngôn ngữ trong các ứng dụng của mình). Đến năm 2015, Spark hỗ trợ thêm ngôn ngữ R, rất nhanh chóng có tới 18% người dùng R, Python cũng tăng lên 58%.

Năm 2015, Spark trở thành dự án mã nguồn mở sôi động nhất trong lĩnh vực dữ liệu lớn khi thường xuyên được cập nhật bởi hơn 800 lập trình viên từ 200 công ty trên khắp thế giới.

6. Một vài thống kê thú vị

  • 62% số người khảo sát dùng Spark với HDFS, 46% sử dụng với các hệ quản trị CSDL như Cassandra, HBase, Hive, Tachyon, 41% đang sử dụng với Kafka, và 29% đang sử dụng cùng Amazon S3.
  • Đối với hệ quản trị cluster, 56% đang chạy độc lập Spark, 42% sử dụng YARN, và 26% sử dụng Apache Mesos.
  • Đối với ngôn ngữ lập trình, 88% sử dụng Scala, 44% sử dụng Java, và 22% sử dụng Python.
  • Mức độ quan tâm của doanh nghiệp về Spark: 91% về tốc độ tính toán, 77% về việc dễ lập trình, 71% về việc dễ phát triển, 64% về các công cụ phân tích dữ liệu tiên tiến, 52% về real-time streaming.
  • Sử dụng Spark trên 206 hệ thống EC2 để sắp xếp 100TB dữ liệu chỉ tốn 23 phút. Trong khi đó, kỉ lục trước đây trên Hadoop sử dụng MapReduce trên 2,100 máy tính phải tiêu tốn 72 phút. Điều này có nghĩa rằng Spark sắp xếp dữ liệu nhanh gấp 3 lần Hadoop mà chỉ sử dụng ít hơn 10 lần số máy tính.

7. Một số hình ảnh tổng quan về hệ sinh thái BigData

8.Một số site tham khảo về Spark & cách cài đặt, triển khai.

  • https://tech.fpt.com.vn/apache-spark-nhan-to-cong-nghe-moi-trong-cuoc-cach-mang-du-lieu-lon/
  • http://datastrophic.io/core-concepts-architecture-and-internals-of-apache-spark/
  • http://backtobazics.com/big-data/6-steps-to-setup-apache-spark-1-0-1-multi-node-cluster-on-centos/
  • http://davidssysadminnotes.blogspot.com/2016/01/installing-spark-centos-7.html
  • https://mapr.com/blog/performance-tuning-apache-kafkaspark-streaming-system/
  • https://jaceklaskowski.gitbooks.io/mastering-apache-spark/spark-tuning.html
  • http://codingpearls.com/big-data/apache-spark/cai-dat-apache-spark-cluster-tren-he-dieu-hanh-linux-ubuntu.html

 

Read more...[BIGDATA] Apache SPARK
No Comments on [BIGDATA] Apache SPARK
Categories: Tài liệu

Bạn có dám bước ra khỏi vùng an toàn? July 28, 2017

Vùng an toàn (comfort zone) là nơi mà chúng ta luôn cảm thấy thoải mái nhất – một công việc chúng ta đã làm quen tay bao năm qua, một loại sách mà ta luôn chọn mua để đọc hay một môi trường sống mà ở đó ta quen vẫy vùng mà không lo sợ.

Và chẳng có gì là sai nếu ai cũng thích ở trong vùng an toàn như vậy, vì nó khiến ta như “cá gặp nước”, có gì mà lo lắng vì bất kỳ ai hay thứ gì trong nơi đó cũng khiến ta dễ chịu hay được yêu thương và bao bọc. Tuy vậy, sẽ có ngày ta chợt nhận thấy: Sao cuộc sống này thật quá đơn điệu và buồn tẻ?
Để bước ra khỏi vùng an toàn, chúng ta cần rất nhiều sự dũng cảm. Trước hết, chúng ta phải chuẩn bị tâm thế rằng ở môi trường mới có thể mọi thứ sẽ không hề thuận lợi. Công việc mới sẽ có những quy trình mới, người đồng nghiệp mới, vì thế mà không phải ai cũng sẽ hiểu bạn hay bạn có thể hiểu rõ cách công việc đó được thực hiện tốt nhất.
Một loại sách mới chắc gì đã hay, vì vốn bạn chỉ thích những điều ngọt ngào mà thứ sách bạn đang thử đọc lại quá khô khan. Một nơi ở mới có nhiều phong tục tập quán mới và những con người lạ lẫm. Vì thế, sự dũng cảm dám trải nghiệm phải là điều kiện tiên quyết để bạn quyết định mở rộng hay chuyển đổi vùng an toàn của mình.
Nhưng tại sao chúng ta lại phải thay đổi nó? Có thực sự cần thiết để thay đổi hay không?
Tôi sẽ kể các bạn nghe câu chuyện mà có lẽ nhiều người trong chúng ta cảm thấy quen thuộc. Thuở nhỏ, chúng ta hay nhìn cuộc sống xung quanh bằng con mắt e dè, đầy hoài nghi và lo sợ. Cha mẹ chúng ta luôn nói rằng “ngoài kia có ông kẹ đấy, ông sẽ bắt nhốt chúng ta vào bao và bán đi”.
Và thế là chúng ta cứ quanh quẩn trong nhà, bên mẹ hay chỉ đi ra ngoài khi có người đi cùng. Rồi đến khi chọn trường đại học, chúng ta cũng sẽ chỉ dám nghe theo ý của cha mẹ. Chúng ta sợ làm khác theo những gì được dạy, cũng sợ “ngoài kia có ông kẹ” nếu mình không làm theo những gì người lớn chỉ dẫn.
Tuy vậy, khi bước vào môi trường học thật sự, chúng ta đâu thể cứ luôn sợ hãi, không dám ra khỏi nhà, hay đi học cũng không dám nói chuyện với ai (trừ những người bạn cũ). Và có khi nào bạn tự hỏi, chúng ta rồi sẽ đi về đâu khi đến lúc chúng ta phải sống cuộc đời của mình và tự ra quyết định cho những vấn đề trong cuộc sống khi người thân không còn ở đó?
Bạn không thể là một nhà giáo giỏi nếu điều bạn muốn truyền đạt không thể được diễn đạt gẫy gọn và dễ hiểu. Bạn cũng không thể là một người lãnh đạo tốt nếu bạn luôn chỉ thích làm theo ý người khác và lo sợ ý kiến của mình bị phản bác.
Rõ ràng đó chính là lúc bạn thấy mình cần “sinh tồn” theo bản năng, nếu bạn không đi thì bạn đang đứng tại chỗ, nếu bạn càng đứng ở “vùng an toàn” càng lâu thì điều đó sẽ càng khiến bạn bị đào thải nhanh.
Bước ra khỏi vùng an toàn
Cũng có những trường hợp bạn muốn mình bước ra khỏi “vùng an toàn” để mở mang kiến thức, để có nhiều trải nghiệm, để thấy thế giới này bao la và rộng lớn. Vì thế giới luôn thay đổi, luôn biến đổi không ngừng khiến cho điều ta hiểu biết càng lúc càng trở nên lỗi thời.
Vì không phải việc lặp đi lặp lại có thể khiến chúng ta là người thợ lành nghề mà chúng ta còn phải là một người thợ khéo léo và tinh tế. Bản thân ta có thấy chán với chính ta nếu như ngày nào chúng ta cũng mặc lên người những bộ quần áo như nhau từ kiểu dáng đến màu sắc? Chúng ta có thấy rằng đã quá lâu có ai đó phải trầm trồ khen ngợi vì ta có những bước thay đổi tích cực.
Ngày nay, bước ra khỏi vùng an toàn chính là “dám dấn thân và dám thay đổi”. Các bạn có thể thay đổi một cách từ từ để mình tập quen với hình ảnh con người mới, với những thay đổi quanh ta.
Có nhiều sinh viên cứ nói với tôi “em cũng không biết mình thích gì cả, cũng không biết mình có thể làm được gì nếu em ra trường”. Nếu chính em còn không biết thì làm sao tôi có thể biết để dẫn đường cho em. Chính em còn không thể hiểu em là ai và em thích gì thì cả chục bài trắc nghiệm về bản thân cũng chỉ là làm cho vui mà thôi.
Đã đến lúc em nghiêm túc nhìn nhận bản thân, và dấn thân để thử xem mình thích ngành nghề nào hay nó có phù hợp với em không. Giáo viên hay bất kỳ ai cũng chỉ có thể giúp em định hình đường đi nhưng chính em mới quyết định được mình nên đi hay không hoặc có dám thử nó hay không.
Trong thời đại công nghệ như hiện nay, việc dám dấn thân và dám nhận lấy những rủi ro cũng là những yếu tố để giúp em bản lĩnh và thành công hơn. Bước ra khỏi vùng an toàn bằng cách dám hỏi, dám nói, dám nhận chỉ trích, dám đối diện với bản thân và thất bại sẽ luôn khó khăn nhưng hãy dũng cảm lên nhé…
Cuộc sống thú vị đang chờ chúng ta ngoài kia!

Theo Trí Thức Trẻ

Read more...Bạn có dám bước ra khỏi vùng an toàn?
No Comments on Bạn có dám bước ra khỏi vùng an toàn?
Categories: Linh tinh

[BigData] Hadoop July 27, 2017

1> Hadoop là gì?
    + Hadoop là một Apache framework mã nguồn mở được viết bằng java, cho phép xử lý phân tán (distributed processing).
    + Ý tưởng chính của Hadoop là việc chia nhỏ và lưu dữ liệu ở trên một nhóm nhiều máy tính, và khi muốn thao tác với dữ liệu chúng ta sẽ xử lý    ngay trên máy mà dữ liệu đó được lưu trữ, giúp tiết kiệm thời gian lấy dữ liệu ở nơi khác. Ngoài ra cấu trúc của Hadoop cũng giúp việc Scale hệ thống theo chiều ngang (Horizontal Scaling) trở nên dễ dàng.
2> Kiến trúc Hadoop
Hadoop framework gồm 4 module:

  • Hadoop Common: Đây là các thư viện và tiện ích cần thiết của Java để các module khác sử dụng. Những thư viện này cung cấp hệ thống file và lớp OS trừu tượng, đồng thời chứa các mã lệnh Java để khởi động Hadoop.
  • Hadoop YARN: Đây là framework để quản lý tiến trình và tài nguyên của các cluster.
  • Hadoop Distributed File System (HDFS): Đây là hệ thống file phân tán cung cấp truy cập thông lượng cao cho ứng dụng khai thác dữ liệu.
  • Hadoop MapReduce: Đây là hệ thống dựa trên YARN dùng để xử lý song song các tập dữ liệu lớn.

Có thể sử dụng sơ đồ sau để mô tả bốn thành phần có trong Hadoop framework:

 2.1 MapReduce
Hadoop MapReduce là một framework dùng để viết các ứng dụng xử lý song song một lượng lớn dữ liệu có khả năng chịu lỗi cao, xuyên suốt hàng ngàn cụm máy tính.
Thuật ngữ MapReduce liên quan đến hai tác vụ mà chương trình Hadoop thực hiện:

  • Map: đây là tác vụ đầu tiên, trong đó dữ liệu đầu vào được chuyển đổi thành tập dữ liệu theo cặp key/value.
  • Reduce: tác vụ này nhận kết quả đầu ra từ tác vụ Map, kết hợp dữ liệu lại với nhau thành tập dữ liệu nhỏ hơn.

Thông thường, kết quả input và output được lưu trong hệ thống file. Framework này sẽ tự động quản lý, theo dõi và tái thực thi các tác vụ bị lỗi.
MapReduce framework gồm một single master JobTracker và các slave  TaskTracker trên mỗi cluster-node. Master có nhiệm vụ quản lý tài   nguyên, theo dõi quá trình sử dụng tài nguyên và lập lịch quản lý các tác vụ trên slave , theo dõi chúng và thực thi lại các tác vụ bị lỗi. Những máy slave TaskTracker thực thi các tác vụ được master chỉ định và cung cấp thông tin trạng thái tác vụ (task-status) để master theo dõi.
JobTracker là một điểm yếu của Hadoop Mapreduce. Nếu JobTracker bị lỗi thì mọi công việc liên quan sẽ bị ngắt quãng.
  2.2 HDFS (Hadoop Distributed File System)
+ Hadoop có thể làm việc trực tiếp với bất kì hệ thống dữ liệu phân tán như Local FS, HFTP FS, S3 FS, và các hệ thống khác. Nhưng hệ thống   file thường được dùng bởi Hadoop là Hadoop Distributed File System (HDFS).
+ Hadoop Distributed File System (HDFS) dựa trên Google File System (GFS), cung cấp một hệ thống dữ liệu phân tán, được thiết kế để chạy trên các cụm máy tính lớn (gồm hàng ngàn máy tính) có khả năng chịu lỗi cao.
+ HDFS sử dụng kiến trúc master/slave, trong đó master gồm một NameNode để quản lý hệ thống file metadata và một hay nhiều slave DataNodes để lưu trữ dữ liệu thực tại.
Một tập tin với định dạng HDFS được chia thành nhiều block và những block này được lưu trữ trong một tập các DataNodes. NameNode định nghĩa ánh xạ từ các block đến các DataNode. Các DataNode điều hành các tác vụ đọc và ghi dữ liệu lên hệ thống file. Chúng cũng quản lý việc tạo, huỷ, và nhân rộng các block thông qua các chỉ thị từ NameNode.
HDFS cũng hỗ trợ các câu lệnh shell để tương tác với tập tin như các hệ thống file khác.
3. Hadoop hoạt động như thế nào?
Giai đoạn 1
Một user hay một ứng dụng có thể submit một job lên Hadoop (hadoop job client) với yêu cầu xử lý cùng các thông tin cơ bản:

  1. Nơi lưu (location) dữ liệu input, output trên hệ thống dữ liệu phân tán.
  2. Các java class ở định dạng jar chứa các dòng lệnh thực thi các hàm map và reduce.
  3. Các thiết lập cụ thể liên quan đến job thông qua các thông số truyền vào.

Giai đoạn 2
Hadoop job client submit job (file jar, file thực thi) và các thiết lập cho JobTracker. Sau đó, master sẽ phân phối tác vụ đến các máy slave để theo dõi và quản lý tiến trình các máy này, đồng thời cung cấp thông tin về tình trạng và chẩn đoán liên quan đến job-client.
Giai đoạn 3
TaskTrackers trên các node khác nhau thực thi tác vụ MapReduce và trả về kết quả output được lưu trong hệ thống file.
4. Ưu điểm của Hadoop

  • Hadoop framework cho phép người dùng nhanh chóng viết và kiểm tra các hệ thống phân tán. Đây là cách hiệu quả cho phép phân phối dữ liệu và công việc xuyên suốt các máy trạm nhờ vào cơ chế xử lý song song của các lõi CPU.
  • Hadoop không dựa vào cơ chế chịu lỗi của phần cứng fault-tolerance and high availability (FTHA), thay vì vậy bản thân Hadoop có các thư viện được thiết kế để phát hiện và xử lý các lỗi ở lớp ứng dụng.
  • Các server có thể được thêm vào hoặc gỡ bỏ từ cluster một cách linh hoạt và vẫn hoạt động mà không bị ngắt quãng.
  • Một lợi thế lớn của Hadoop ngoài mã nguồn mở đó là khả năng tương thích trên tất cả các nền tảng do được phát triển trên Java.


Một số site tham khảo về hadoop:
https://ongxuanhong.wordpress.com/2015/11/15/top-free-hadoop-tutorials/
https://ongxuanhong.wordpress.com/2015/08/17/nen-chon-hadoop-hay-spark-cho-he-thong-big-data/
http://saphanatutorial.com/hadoop-1-0-vs-hadoop-2-0/
http://phamquan.com/big-data/big-data-co-ban
http://www.corejavaguru.com/bigdata/index

How to Install and Configure Apache Hadoop on a Single Node in CentOS 7


https://www.edureka.co/blog/install-hadoop-single-node-hadoop-cluster

Read more...[BigData] Hadoop
No Comments on [BigData] Hadoop
Categories: Tài liệu

Con đường sự nghiệp của 1 *nix system admin July 25, 2017

Khi đã và đang làm việc như là 1 system admin, “một nghề cao quý trong những nghề cao quý”, bạn sẽ dần được trải qua những mốc ghi dấu của con đường sự nghiệp của mình, 1 vài giây nhìn lại những nấc thang mà bạn đã vượt qua, nếu như bạn sẽ và mới bắt đầu với con đường này, đây là bài viết cho bạn 1 cái nhìn tổng quan nhất, giúp bạn định hình được những thứ bạn sẽ phải trải qua, tuy khó khăn gian khổ, nhưng trái ngọt luôn chờ bạn 🙂

Level 0
Bắt đầu sẽ là 1 cái title dành cho các bạn học sinh, sinh viên, lúc còn đang học ở trường, trung tâm đào tạo …Đây là thời điểm bạn được bắt đầu làm quen với mọi thứ, những lý thuyết cơ bản nhất về mạng máy tính, về hạ tầng mạng và hệ thống, về lập trình cơ bản, về bảo mật và an toàn thông tin.. Tất cả là 1 mớ lý thuyết vô cùng to lớn được gói gọn trong 1 chương trình học cực kỳ ngắn, thường là 1-2 môn trong 1-2 học kỳ, hoặc là 1 khóa đào tạo ngắn hạn từ 3-4 tháng.  Bạn rất may mắn khi đã được trải qua level này với đầy đủ lý thuyết và phần thực hành tương xứng, nếu có những bài luận văn hay chứng chỉ về mạng và hệ thống trong thời điểm này hoặc được nhận vào thực tập ở 1 công ty lớn thì thật là tuyệt.
Bạn sẽ ghi toàn bộ những thứ mình học và làm được trong hồ sơ xin việc của mình và gửi nó đi khắp nơi, nếu may mắn, nghề sẽ chọn được bạn và bạn sẽ bắt đầu cuộc phiêu lưu của mình ở level khác.

Entry/Junior Level
Đây là level bạn sẽ bắt đầu khi mới vào nghề và từ 6 tháng đến 2 năm, và ở level này, bạn cần đạt được những yêu cầu như sau:
Về kiến thức hệ thống

“- Nắm vững kiến thức cơ bản về mạng: các protocol cơ bản (DHCP, ARP, DNS…), NAT & firewall, các trạng thái của kết nối TCP
– Nắm kiến thức cơ bản về phần cứng, chủ yếu là các chỉ số system utilization: CPU (# cores, frequency), RAM (frequency), Disk (IOPS)
– Các kiến thức cơ bản của OS (linux/Windows): process & thread, các service cơ bản, permission & policy
– Các kiến thức cơ bản về Databases: MySQL, Oracle, …”

Về kỹ năng vận hành

“- Có khả năng sử dụng các công cụ cơ bản để quản lý, theo dõi và phân tích các vấn đề kỹ thuật (ssh/Remote Desktop, ping, netstat, top/htop…)
– Hiểu & tuân thủ quy trình vận hành, cài đặt & bảo trì hệ thống
– Có khả năng xử lý sự cố mức độ thấp”

Về bảo mật

“- Có kiến thức cơ bản về các khái niệm bảo mật: ACL, virus, spyware, backdoor
– Có kiến thức, kỹ năng trong việc đảm bảo bảo mật mức thấp (setup firewall, sử dụng anti-virus)
– Tuân thủ quy trình và các nguyên tắc bảo mật”

Về nghiên cứu và ứng dụng

“- Có khả năng ứng dụng công nghệ mới vào công việc vận hành hàng ngày”

Mid Level
Đây là nấc thang tiếp theo, bạn sẽ đạt được sau khoảng từ 2 năm tới 3 năm 😀 nhanh hay lâu tùy thuộc vào bản thân của bạn, nhưng tối thiểu bạn phải đáp ứng được những yêu cầu sau:
Về kiến thức hệ thống

“- Nắm vững kiến thức chuyên sâu về mạng: phân biệt & hiểu rõ tất cả các tầng của OSI model
– Nắm vững kiến thức về quá trình phần cứng vận hành & sự phối hợp của các phần cứng trong một hệ thống
– Có kiến thức về optimization, high scalibility, high performance, high availability”

Về kỹ năng vận hành

“- Có khả năng tối ưu hóa hệ thống ở mức vừa (tăng ít nhất 10% hiệu suất hệ thống có sẵn, có ít nhất 5 server)
– Có khả năng xử lý, tìm ra nguyên nhân & khắc phục các sự cố có độ phức tạp vừa
– Vận hành, theo dõi & bảo trì bằng script (automation)
– Theo dõi & phát hiện các nguy cơ tiềm ẩn trong hệ thống mình quản lý & theo dõi”

Về bảo mật

“- Thực hiện kiểm tra & đánh giá nguy cơ bảo mật định kỳ & mỗi khi hệ thống được cập nhật
– Có khả năng khắc phục, xử lý các sự cố liên quan đến bảo mật ở mức độ vừa (xử lý backdoor/virus, vá lỗ hổng bảo mật…)”

Về nghiên cứu và ứng dụng

“- Chủ động nghiên cứu, đánh giá các công nghệ mới để áp dụng vào công việc vận hành chung của team”

Senior Level 
Đây là thành quả cày cuốc của bạn sau từ 3-5 năm, bạn sẽ đạt được level này:
Về kiến thức hệ thống

“- Nắm vững kiến thức chuyên sâu về hệ điều hành: Linux kernel, Windows architecture (kernel, drivers, HAL…)
– Có kiến thức về thư viện, framework mà các software service sử dụng (libc, jdk, php, .NET…)”

Về kỹ năng vận hành

“- Có thể thiết kế, tư vấn, đánh giá & triển khai các giải pháp kỹ thuật phức tạp cho hệ thống lớn (>20 server)
– Quản lý và phân công các team giải quyết các sự cố có độ phức tạp cao
– Chịu trách nhiệm chính, ra quyết định trong các dự án lớn”

Về bảo mật

“- Chuyên sâu trong lĩnh vực bảo mật: có cơ chế/giải pháp hạn chế các rủi ro bảo mật có thể xảy ra
– Hỗ trợ, tư vấn trong việc phòng chống, điều tra và xử lý các lỗi bảo mật trong phạm vi toàn công ty”

Về nghiên cứu và ứng dụng

“- Có khả năng tự nghiên cứu, phát triển & triển khai các giải pháp phức tạp phục vụ cho mục tiêu tối ưu hóa công nghệ, mang lại lơi ích kinh doanh (tính năng ưu việt, cắt giảm chi phí…)”


Bài viết chỉ mới đề cập tới các level liên quan tới cấp bậc là nhân viên, chưa đề cập tới các cấp bậc khác như trưởng nhóm, giám sát hay quản lý và cũng là ý kiến chủ quan của cá nhân mình nên có thể không đúng hoàn toàn khi áp dụng vào công ty hay cho bản thân bạn, vì hiện tại mình cũng chưa trải qua những cấp bậc đó nên chưa viết 🙂 Đón đọc blog của mình sau 5 – 10 năm nữa nhé.

Read more...Con đường sự nghiệp của 1 *nix system admin
2 Comments on Con đường sự nghiệp của 1 *nix system admin
Tags: , , , ,
Categories: Chuyện nghề Linh tinh

Những đức tính cần có cho việc "sống còn" của 1 system admin July 16, 2017


Dấn thân vào với nghề system admin, cũng như bất kỳ 1 ngành nghề nào khác trong lĩnh vực công nghệ thông tin, bạn luôn phải đối diện với những áp lực, những khó khăn, làm thế nào để vượt qua, làm sao để sống còn với còn đường mình đã chọn? Người ta thường nói, việc chọn người, nhưng khi bạn đã chọn system admin là nghề của bạn, bạn cần rèn luyện cho mình những “đức tính” cần thiết sau.

  • Tính cẩn thận

Tại sao lại đặt tính cẩn thận lên hàng đầu?, vì khi bạn là 1 system admin, mọi thứ liên quan đến hoạt động của hệ thống, việc duy trì và đảm bảo tính ổn định của hệ thống là yếu tố hàng đầu và là yếu tố duy nhất để người ta trả tiền cho bạn. Bất kỳ sự sai sót nhỏ nào của bạn, đều ảnh hưởng đến hệ thống, nhất là những hệ thống dữ liệu, hệ thống thanh toán, hệ thống đăng nhập… sai 1 ly là đi ngàn dặm 🙂
Cẩn thận có thể rèn luyện được, nhưng không phải là trong 1 hay vài ngày, có người có khi cả đời cũng không thể nào “cẩn thận” được. Vậy việc cẩn thận của system admin thể hiện như thế nào, dưới đây là 1 số thứ mà tôi khuyên bạn cần làm để có đươc nó.
Luôn luôn backup mọi thứ, như file cấu hình hệ thống, bản cài đặt version cũ hơn, dùng mv chứ đừng dùng rm 🙂
Luôn ghi lại step by step những thao tác bạn định làm, cho dù đó là những thao tác bạn làm thuần thục và thường xuyên nhất, luôn ghi nhớ là bạn đã thực hiện tới bước nào, còn sót bước nào không, sau khi thực hiện xong cần kiểm tra lại 1 lần nữa về những thứ bạn đã thay đổi trong hệ thống.
Luôn kiểm tra whoami bằng command cũng như chắc chắn khi gõ init 0 hay reboot bất kỳ 1 sheet của terminal hay nhấn Ctr+Alt+Del , có thể bạn đang reboot production server chứ không phải là máy local của bạn 🙂

  • Chịu khó

Khi bạn chọn theo nghề này, đừng bao giờ than phiền khi thức giấc lúc nửa đêm và làm việc cho tới sáng hôm sau, hay thức vài đêm liền ngồi trong datacenter, bưng vài chục con server từ tầng hầm lên tầng 2, hay đang ngoài đường, trời nắng hay mưa thì khi có cuộc gọi hoặc alert từ hệ thống bạn đều phải sẵn sàng xử lý ngay lập tức. Có nghĩa là bạn sẽ phải có đức tính chịu khó và không có ngày nghỉ nào đích thực khi chọn nghề này.
Vậy bạn rèn luyện tính “chịu khó” như thế nào? Theo tôi thì khi chọn nghề, bạn đã có sẵn tính này rồi, nếu không thì bạn sẽ chọn việc nhẹ nhàng và gian khổ này đã để dành phần tôi 🙂

  • Chịu được áp lực

Áp lực luôn có, dù hữu hình hay vô hình, và bạn luôn phải đối diện với nó. Khi hệ thống ổn định, và hoạt động trơn tru, áp lực của bạn là phải làm sao để tối ưu hóa hệ thống, làm sao để giảm chi phí, tài nguyên khi vận hành nó, bạn phải nghĩ cách làm sao tự động hóa tất cả các thao tác, giảm thiểu rủi ro cho hệ thống. Nhưng như vậy, đó là 1 áp lực dễ chịu, không cần phải đề cập quá sâu vào vấn đề này.
Áp lực thực sự khi có sự cố xảy ra, và ví dụ như bạn chỉ có 1 mình để giải quyết chẳng hạn, bạn phải có tinh thần thép để vượt qua nó. Chịu được áp lực là chịu được lời của sếp bên tai, lời của khách hàng la ó, lời của đồng nghiệp … Phải thật bình tĩnh để xử lý sự cố cũng như chuẩn bị tinh thần thép để giải trình sự cố 1 cách tối ưu nhất.
Có thể áp lực cũng đến khi bạn phải làm report hàng ngày, phải chịu sự coaching của sếp trực tiếp, hoặc áp lực đến từ những thứ người khác giao cho bạn và quá khả năng của bản thân bạn.
Vậy bạn rèn luyện đức tính này như thế nào? Theo tôi, luôn có 1 ngưỡng được đặt ra cho bản thân, khi bạn vượt qua chính bản thân, thì chả có áp lực nào dù hữu hình hay vô hình làm khó được bạn. Thắng chính bản thân mình sẽ vượt qua áp lực.

  • Trung thực

Tại sao trung thực là điều cần có của 1 system admin? Bạn trung thực nhận lỗi khi bạn đã làm sai, bạn trung thực với sếp, với khách hàng, với đồng nghiệp và với bản thân mình. Đừng cố tính đá quả bóng trách nhiệm của mình cho người khác, mà hãy dũng cảm đối mặt với nó. Tuy nhiên, thẳng thắn thường thua thiệt, ngành nghề nào cũng vậy, nhưng riêng với tôi, giá trị của bản thân bạn nó đến từ cái lõi trong tâm.
Rèn luyện tính trung thực bằng cách nào? Bản thân tôi cũng không rõ nữa, nhưng chân thành với đồng nghiệp, trung thực với mọi người khiến bạn sẽ trở thành 1 người có tâm và sẽ “còn sống” với nghề của bạn được lâu nữa.

  • Ham học hỏi

Ngành công nghệ thông tin đang phát triển như vũ bão, đứng im có nghĩa là bạn đã thụt lùi, và khi mọi người sẵn sàng bỏ lại quá xa thì bạn sẽ bị gạt bỏ ra khỏi guồng quay của nó. Vì vậy, sống còn với bạn có nghĩa là khi bạn sẵn sàng học hỏi và tiếp thu cái mới, không bảo thủ với những thứ trước đây mà bạn nghĩ là phù hợp.
Đọc sách, học hỏi từ cộng đồng, từ đồng nghiệp, từ sếp, từ khách hàng thậm chí là từ những fresher mà bạn nhận training. Đừng ngại khi trao đổi và chia sẻ những kiến thức mà mình có được, đó cũng là 1 cách học hỏi người khác.

  • Bày tỏ quan điểm, ý kiến

Để sống còn, bạn cần phải bày tỏ quan điểm của mình với người khác, không phải là tranh cãi tới cùng, không phải là sống chết để bảo vệ ý kiến của mình, nhưng bạn cần có chính kiến của mình. Tuy nhiên, cách trình bày ý kiến cũng là 1 nghệ thuật, bạn góp ý thì nên nhẹ nhàng, bạn là sếp thì giao việc 1 cách nhẹ nhàng, không vô tình tạo áp lực, khi bạn là lính, bạn không nên thẳng thắn quá khi thấy sếp hay đồng nghiệp sai. Nếu ý kiến của bạn không được đám đông hưởng ứng, cũng đừng quá bức xúc mà tỏ thái độ, điều đó không tốt cho ai cả.
Đây thực sự là 1 nghệ thuật, trong bài viết này chắc chắn sẽ không nói ra hết được, tuy nhiên, bạn là người có chính kiến, tôi sẽ tôn trọng bạn.

  • Biết lắng nghe

Ngoài việc biết bày tỏ ý kiến, thì lắng nghe cũng là 1 đức tính bạn cần có, luôn luôn lắng nghe, luôn luôn chia sẻ, bạn hãy luôn làm như thế. Hãy luôn là người biết lắng nghe khi người khác bày tỏ quan điểm, ý kiến, nguyện vọng của mình, đừng nên nhảy thẳng vào miệng khi người khác mở lời, cũng không nên trù dập ý kiến của người khác khi vừa mới nói ra.
Lắng nghe, không có nghĩa là phục tùng tuyệt đối, là nghe lời như mẹ bảo con.

Trên đây là 1 vài đức tính cần có và nên được rèn luyện của những người đã và đang chọn system admin là đam mê của mình, nếu bạn chưa có những đức tính trên, cũng không sao, mọi thứ đều có thể rèn luyện được, nếu bạn đã có những thứ trên thì chúc mừng bạn đã “sống”.

 
 

Read more...Những đức tính cần có cho việc "sống còn" của 1 system admin
No Comments on Những đức tính cần có cho việc "sống còn" của 1 system admin
Categories: Chuyện nghề

Chuyện đời chuyện nghề của 1 system cùi bắp long dong ở nhiều cty :v

Trong cái nghề SE/SO/SA mỗi anh em sẽ có những trải nghiệm khác nhau, những cách đánh giá khác nhau trong công việc mình đang làm, môi trường mình đang công tác, riêng đối với bản thân mình mặc dù là số năm kinh nghiệm xông pha trận mạc trong nghề này chưa gì là ghê gớm những cũng đã nhảy nhót qua 4-5 công ty, có tháng move 2-3 công ty.
Nghe đến đây chắc hẳn nhìn vào ai cũng có một cách nhìn riêng, có thể có người cho mình không chịu khó, không kiên trì trong công việc thấy khó là nản, có người đồng cảm hơn thì nghĩ chắc vì lí do nào đó mới off, thật sự mà nói khi lần đầu bước vào một công ty ta cũng không hề biết trước điều gì sẽ chờ ta ở đó, có thể mình đã tìm hiểu trước về công ty đó (chính sách, môi trường, công việc ….) qua bạn bè làm ở đó, qua các trang tin, qua sự PR của HR :v để có một niềm tin nhất định, ai cũng mong muốn một chỗ làm ổn định, salary ổn ổn, môi trường good, blabla các thứ.
Ok! Sau khi đã join vào một time, công việc lúc đầu suôn sẻ, môi trường ko đến nổi, nhân viên thân thiện,…. Thời điểm này bản thân sẽ thấy thoải mái và nghĩ có thể nơi đây là bến đỗ hợp lý bản thân không phải nghĩ ngợi gì nhiều chỉ cố gắng làm và làm. Thế rồi những time sau đó dự án nhiều kéo theo việc nhiều, time OT ngày càng tăng, khối lượng công việc càng lớn, sếp dí deadline, có những việc bản thân không biết phải xử lý( có thể còn gà quá mò hoài ko ra, tìm kiếm sự support cũng hạn chế), cho đến thời điểm gần deadline lại cuống lên thế là xì trét, áp lực tình trạng này kéo dài vài tháng  thế là chịu không thấu xin off ( lúc này đã tìm đường binh đến một chỗ khác) => đây có thể hiểu tùy vào năng lực + suy nghĩ của mỗi người ( nếu gặp người chuyên môn tốt, kinh nghiệm xử lý qua nhiều thì chuyện này chả là gì nhưng đối với mấy kẻ gà gà nếu công việc chỉ đơn độc xử lý 1 mình ko nhận được sự support thì rất dễ bức tóc :v & ra đi).
Sau khi off cty đầu tiên và qua cty tiếp theo gặp phải môi trường  Nhật thấy xưa giờ chưa quen kiểu làm việc khắt khe thế cảm thấy ngộp và lại off , rồi tiếp nối những tháng ngày đen tối đến một bến đỗ khác, ở môi trường này được cái time làm việc cũng dễ thở, không phải bị ép deadline nhưng giai đoạn đầu là thế,vào các time sau đó hệ thống lỗi triền miên, bản thân là ôm đồm nhiều thứ từ hệ thống Core đến hệ thống Game, kiêm luôn cả các việc lặt vặt khác mà lead vs sếp sai bảo, đỉnh điểm là hầu như trong 1 tháng tuần nào cũng OT, cuối tuần cũng phải OT, có hôm làm gần 24 tiếng, ngày ngày lên cty cũng bị ăn hành + ăn chửi từ lead, lúc làm việc thì ngồi cạnh bên giám sát, soi xét từng thao tác :v, những ngày dài sau đó chỉ suốt ngày là debug, fix lỗi, nghe chửi, nghe giáo huấn các kiểu :v
=> Lần này em nó off vì không hợp với cách làm việc với lead, không có một không gian + môi trường làm việc thoải mái.
Túm váy lại thì chuyện ở hay đi ở một công ty nó có nhiều yếu tố, mỗi môi trường có mỗi văn hóa vs quy trình làm việc khác nhau, quan trọng là bản thân có hòa hợp được vào môi trường đó hay không, cố gắng cố gắng trong công việc không là chưa đủ, có những thứ khi bạn join vào môi trường đó mới tường tận cảm nhận được, chẳng ai là  không muốn tìm được một môi trường tốt nhưng việc ra đi hay ở lại nó đến từ cả chính sự cố gắng của bạn + môi trường bạn đang làm, trải nghiệm nhiều công ty bản thân mình nghiệm ra ở môi trường nào cũng sẽ có cái mặt trái của nó, không nới nào đáp ứng hết được các mong muốn của bạn cùng lúc, được này sẽ mất kia (nhưng  được vs mất bản thân chấp nhận được) nhưng trước tiên bản thân bạn phải nổ lực hết mình việc còn lại để cty lo, lo không xong thì lúc đấy bạn biết phải làm gì rồi đấy :v.

Read more...Chuyện đời chuyện nghề của 1 system cùi bắp long dong ở nhiều cty :v
No Comments on Chuyện đời chuyện nghề của 1 system cùi bắp long dong ở nhiều cty :v
Categories: Chuyện nghề

Hướng dẫn compile Nginx từ source trên Centos July 14, 2017


Nginx là gì?

NGINX (Pronounced as Engine-X) is an open source, lightweight, high-performance web server or proxy server. Nginx used as reverse proxy server for HTTP, HTTPS, SMTP, IMAP, POP3 protocols, on the other hand, it is also used for servers load balancing and HTTP Cache. Nginx accelerates content and application delivery, improves security, facilitates availability and scalability for the busiest websites on the Internet.

Trong bài viết này mình không đi sâu về khái niệm cũng như chi tiết của nginx, vì ngoài là 1 phần mễm mã nguồn mở thì bên trong nó là cả 1 đại dương rộng lớn về ngôn ngữ, cấu hình, cách hoạt động, tính năng, hiệu suất… mà chỉ để cập tới việc cài đặt nó, nhưng không dùng cách thông thường là cài đặt từ yum mà là complile từ source.

Compile Nginx from source with SSL support

  • Install dependencies

yum install pcre pcre-devel zlib zlib-devel
wget https://www.openssl.org/source/openssl-1.1.0e.tar.gz
tar -xvzf openssl-1.1.0e.tar.gz
cd openssl-1.1.0e/
./config –openssldir=/usr/local/ssl
make
make install
openssl version

  • Compile nginx to custom location

wget http://nginx.org/download/nginx-1.12.0.tar.gz
tar -xvzf nginx-1.12.0.tar.gz
cd nginx-1.12.0
./configure –prefix=/zserver/nginx –with-http_gzip_static_module –with-http_stub_status_module –with-http_ssl_module –with-openssl=/path/to/openssl-1.1.0e
make
make install
/zserver/nginx/sbin/nginx -V
nginx version: nginx/1.12.0
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC)
built with OpenSSL 1.1.0e 16 Feb 2017
TLS SNI support enabled
configure arguments: –prefix=/zserver/nginx –with-http_gzip_static_module –with-http_stub_status_module –with-http_ssl_module –with-openssl=/root/sources/openssl-1.1.0e

  • More information

http://nginx.org/en/docs/configure.html

Read more...Hướng dẫn compile Nginx từ source trên Centos
No Comments on Hướng dẫn compile Nginx từ source trên Centos
Tags: , ,
Categories: Tài liệu

Sysadmin nghĩ về mọi người như thế nào? July 12, 2017

Google mãi cũng ra được tấm hình http://imgur.com/vRTRP

Khi bạn làm việc trong 1 môi trường production trong vai trò của 1 system admin, bạn sẽ được tiếp xúc mà làm việc với những người như là developer, tester/QC, project manager, designer … hay chính những đồng nghiệp sysadmin như mình. Vậy trong mắt bạn, họ là những ai? Hay mọi người nghĩ gì về bạn ? Bài viết sẽ chia sẻ những suy nghĩ của bản thân mình về họ :D. Đây là ý kiến chủ quan của cá nhân của tác giả, và chỉ phù hợp với mục tiêu chém gió.
Developer
Công việc của bạn khi làm trong 1 công ty production hay outsource chủ yếu là xây dựng hệ thống và môi trường cho developer làm việc và thường gặp gỡ nhau ở môi trường sandbox. Mọi thứ đều sẽ do bạn cài đặt lên theo yêu cầu của dev hoặc dựa theo framework có sẵn của từng công ty. Dev không được tự ý thay đổi, hay tự cài đặt cho riêng mình và chỉ dùng được user có giới hạn quyền, nên trong mắt của bạn, dev chỉ là những “gã khờ”, với cái răng gãy (như hình trên), họ không thể thay đổi gì trên hệ thống ngoài code của chính họ, họ cũng không thể truy cập vào server nếu như bạn không mở firewall hay cấp quyền, mật khẩu…Đơn giản là họ cũng không thể nào shutdown hệ thống sandbox khi buồn hay đái vào server để đi ngủ khi debug giữa đêm khuya được.
Tuy nhiên, đối với bạn thì developer là người nắm rõ hệ thống, luôn được đánh giá cao bởi khả năng cày cuốc, cũng như chịu được áp lực công việc được đặt ra từ PM, họ luôn giải quyết vấn đề 1 cách chính xác và nhanh chóng, ít nhất thì cũng đúng deadline.
QC
Nhiều công ty thì QC có thể là QC, QA và đảm nhiệm luôn vai trò tester, nên mình gọi chung như vậy. Trong mắt bạn thì họ là những người có ưu điểm là chuyên bới lông tìm vết, bởi vì bug nào cũng tìm ra, issue nào cũng đánh thắng. Tới ngày release chỉ mong được cái confirm hay gật đầu của tester để được xách đích về nhà, có khi còn vui mừng hơn cả team dev.
QC thường yêu cầu bạn cài những phần mềm “xa lạ” để thực hiện quản lý bug, automation, quản lý testcase… và thường báo bug lúc 1-2h sáng và có thể thức cùng sysadmin, dev đến 5h để fix bug hay review sau khi có changes.
Designer
Trong mắt bạn thì designer là những thành phần “chả biết gì” về hệ thống, và hiếm khi đụng chạm gì tới nhau. Nhìn designer lúc nào cũng sạch sẽ, sành điệu, xài toàn hàng hiệu cũng như có gu thẫm mỹ rất khác biệt. Họ chỉ gặp bạn khi không truy cập vào được hệ thống, không commit lên SVN/Git được hay đơn giản là cái hình của họ hiển thị màu không đúng.
Còn gì tuyệt hơn khi được làm việc cùng với những bạn (nhất là nữ) xinh đẹp, dễ thương và có nhiều tài lẻ, nói chung với system admin, designer dùng để ngắm nhiều hơn là làm việc cùng 🙂
Project Manager
Đây là những tên tội phạm truy nã đích thực ( như hình vẽ), luôn có những áp lực được tạo ra bởi PM cho chúng ta. Khi hệ thống chạy tốt, họ chẳng thèm quan tâm đã làm gì, ở đâu, nhưng khi có incident hoặc wifi không vào được, họ sẽ là người tìm và xử lý chúng ta. 🙂 Khi họ trao cho chúng ta nhiều quyền lực hơn thì lại càng áp lực hơn nữa, hệ thống vận hành không tốt, người đầu tiên bị bêu đầu là bạn, còn khi hệ thống tốt thì bạn chắc chắn không phải là người đầu tiên ( có khi quên mất bạn là ai 🙂 j/k)
Làm việc với PM như chơi với cọp 🙂 Thế là đủ
System Admin
Đây là những tên đồng đội của chúng ta hàng ngày, muốn đi nhanh thì đi 1 mình, nhưng đi xa thì phải có đồng đôi. Điều đó luôn đúng và càng đúng khi chúng ta là những người system admin. Họ là những người làm thay việc chúng ta khi ta bận đi chơi với bạn gái, đi đá banh, hay sẵn sàng nhấc điện thoại lên lúc 2h sáng hoặc đang lên cơn sung trong nhà nghỉ. Đôi khi chúng ta hay cho rằng mình là Neo, nhưng thực sự thì không biết đúng hay không nữa 😀
Làm việc với nhau tốt là cách để tồn tại và phát triển trong môi trường hiện tại, nhưng sự cạnh tranh luôn xảy ra, nếu bạn không may phải làm việc 1 mình, thì chúc mừng bạn, vì chỉ có bản thân mình là đối thủ.
Bạn cứ thoải mái nghĩ về người khác, mặc kệ người khác nghĩ gì về chúng ta.
 
 

Read more...Sysadmin nghĩ về mọi người như thế nào?
No Comments on Sysadmin nghĩ về mọi người như thế nào?
Categories: Linh tinh

Hiểu thêm về timezone và localtime trên Centos 6/7 July 10, 2017

Khi tiến hành cài đặt 1 server Centos 6/7, bạn có thể chọn cài đặt Date & Time ngay từ đầu, tuy nhiên, với 1 số VPS hay server trên cloud như Sakura, Google Cloud Engine…timezone phụ thuộc vào nơi mà bạn chọn để đặt server đó. Vì vậy, có thể thời gian của server và thời gian local của bạn không trùng khớp, nên nhất thiết cần phải đặt lại theo múi giờ mình chọn trước.
Trên Centos, thư mục /usr/share/zoneinfo/ là nơi chứa toàn bộ thông tin của các múi giờ của hệ thống.

ls /usr/share/zoneinfo/
Africa Atlantic Chile Eire GB GMT+0 Indian Japan MST Pacific PRC Singapore UTC Zulu
America Australia CST6CDT EST GB-Eire Greenwich Iran Kwajalein MST7MDT Poland PST8PDT Turkey WET
Antarctica Brazil Cuba EST5EDT GMT Hongkong iso3166.tab Libya Navajo Portugal right UCT W-SU
Arctic Canada EET Etc GMT0 HST Israel MET NZ posix ROC Universal zone1970.tab
Asia CET Egypt Europe GMT-0 Iceland Jamaica Mexico NZ-CHAT posixrules ROK US zone.tab

Và file /etc/localtime chính file thể hiện múi giờ hiện tại, thường được symlink tới 1 múi giờ chính xác được quy định trong /usr/share/zoneinfo/
Ví du:

ll /etc/localtime
lrwxrwxrwx 1 root root 30 Jun 12 01:09 /etc/localtime -> /usr/share/zoneinfo/Asia/Tokyo

Có nghĩa múi giờ hiện tại của bạn là “Asia/Tokyo”
Để thay đổi giờ hệ thống cho server của bạn, làm theo các bước sau:
Với Centos 7
Kiểm tra timzone list có sẵn trên hệ thống

timedatectl list-timezones |grep Asia| head
Asia/Aden
Asia/Almaty
Asia/Amman
Asia/Anadyr
Asia/Aqtau
Asia/Aqtobe
Asia/Ashgabat
Asia/Baghdad
Asia/Bahrain
Asia/Baku

Kiểm tra timzone hiện tại

ll /etc/localtime
lrwxrwxrwx. 1 root root 38 Apr 24 2016 /etc/localtime -> ../usr/share/zoneinfo/Asia/Ho_Chi_Minh

Thay đổi timezone bằng câu lệnh

timedatectl set-timezone Asia/Tokyo

Kiểm tra thay đổi

ll /etc/localtime
lrwxrwxrwx. 1 root root 38 Apr 24 2016 /etc/localtime -> ../usr/share/zoneinfo/Asia/Tokyo

Với Centos 6
Xóa file localtime hiện tại ( có thể backup)

rm -rf /etc/localtime

Tạo softlink tới chính xác múi giờ bạn cần

ln -s /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

Thay đổi thời gian trong clock

vi /etc/sysconfig/clock

Change ZONE=”Asia/Tokyo”

hwclock –systohc –localtime

Chúc bạn thành công.
 
 

Read more...Hiểu thêm về timezone và localtime trên Centos 6/7
No Comments on Hiểu thêm về timezone và localtime trên Centos 6/7
Tags:
Categories: Tài liệu
Older »